I appreciate the confirmation. Our OpsMgr 2012 design is definitely going to change with all the points raised here. Thank you for taking the time to help us out.
-Geoff From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Holman Sent: Tuesday, January 27, 2015 7:59 AM To: [email protected] Subject: [msmom] RE: OpsMgr 2012 R2 Architecture Question Your point below is correct. If the OpsDB is offline and down, the entire management group is dead. However, agents will go on monitoring, and then just queue their alerts instead of sending them. UNLESS the outage is significant enough that the agents cannot queue the data and begin to FIFO it. The FIFO for the queue is prioritized... Perf collection data is dropped first, then Event data and finally State and Alert data, because State and Alert data is the most important. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey Sent: Tuesday, January 27, 2015 7:37 AM To: '[email protected]' Subject: [msmom] RE: OpsMgr 2012 R2 Architecture Question Kevin, I just wanted to clarify one point to make sure I'm 100% on it: If a database is offline, the management server will block, and the agents will naturally queue the data on the agent until the database is available again and the management server accepts it. Since "the management servers will block and the agents will queue the data", no alerting will occur while the Ops DB is offline. Then once the Ops DB is available again, the data will come in as expected and alerting will return to normal, yes? Thank you. -Geoff From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kevin Holman Sent: Monday, January 26, 2015 10:09 PM To: [email protected]<mailto:[email protected]> Subject: [msmom] RE: OpsMgr 2012 R2 Architecture Question Below: From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey Sent: Monday, January 26, 2015 3:05 PM To: '[email protected]' Subject: [msmom] RE: OpsMgr 2012 R2 Architecture Question Thanks for the reply Kevin. I recognize your name as I've been using your blogs/articles to help with our existing 2007 R2 environment. At the heart of this, we are trying to achieve no single point of failure, assuming that failure would mean a gap in performance metrics or alerting. If the operational DB can be down for a day, but we would still get alerts from the management servers and performance metrics would still be captured, then a single server would be fine with us. That is why we are okay with the Database Warehouse being a single server, as I was instructed the Operational DB will write any missed information once the Database Warehouse DB is back online. At least, I was told this by the current main Sys Admin in charge of SCOM 2007 R2 (nobody here has experience with 2012 R2). If that is wrong or not the case with 2012 R2, please correct me, as that means we'll have to evaluate a second server for the Database Warehouse. [KH] That is wrong. That is how MOM 2005 worked. SCOM 2007 was a complete change. Agents write their data (perf, alert, state, event, discovery) to a management server, which queues it and writes directly to both databases (OpsDB and DW) simultaneously. Some data (alerts, discovery) are written to the OpsDB only, then are synchronized from the OpsDB to the DW via sync jobs which are executed by the management servers (RMS in SCOM 2007, All Management Servers Resource Pool in SOCM 2012). If a database is offline, the management server will block, and the agents will naturally queue the data on the agent until the database is available again and the management server accepts it. If you want to have a discussion on high availability, we can do that. Generally if you are going to cluster ANY database for HA/DR, you should consider clustering both. In SCOM 2012, the Warehouse is no longer optional, it is a critical database installed with the management group. Dashboards in the console leverage this data directly. If you are designing for business continuity, you have to plan for the replicated warehouse as well in SCOM 2012. As for the licensing, System Center is licensed for SQL Standard edition, correct? So if we wanted the Operational and Warehouse DBs to be highly available (SQL Always On), we'd have to bump our SQL to Enterprise edition and pay for that on our EA and separate from the System Center license, right? [KH] I am not a licensing expert, but yes. Moving to Always On bumps you to Enterprise licensing as I understand it. You can still leverage a legacy 2 node failover cluster using SQL standard. But if you want SQL replication of databases for site resiliency/continuity, Always On is a better option. So the new design would look something like this: 2 Management Servers (agent-based, w/ Web Console on one or both) 2 Management Servers (Resource Pool for network devices) 1 Operational DB Server (or 2 w/ SQL Always On) 1 Data Warehouse DB Server (or 2 w/ SQL Always On) I did see the sizing calculator last week and ran it to get an idea on roles/sizes, but wasn't sure how accurate the spreadsheet is to our specific environment. Sometimes MS says "You need _x_ servers", then we get a PFE in here and the PFE will say "You're so small, you don't even need half that." That happened with ConfigMgr 2012, which we scoped our build per MS documentation, once the PFE was onsite, he recommended slimming it down significantly and ConfigMgr has been humming along fine for the last 12-18mons without issue. So I appreciate the sanity check. [KH] I know what you mean. However when it comes to SCOM most people wish they sized up. Not so much in number of servers, but making sure the SQL servers are not undersized or they will be unhappy with performance. Historically disk I/O was the biggest problem, but company's storage seems to have caught up lately and this is becoming more rare. I still like placing the OpsDB on SSD whenever possible. :) In general, I recommend following the sizing spreadsheet (the DB sizes are a little exaggerated in some cases). If you go over one specific size then I recommend using the next one up. If you were looking to consolidate wherever possible, then you could consider putting the OpsDB and DW on the same SQL server above (or 2 always on nodes), and just bump up the memory and ensure you have good disk I/O. 600 agents is "fairly small" from what I am used to supporting, and I think you will find it will perform nicely. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kevin Holman Sent: Monday, January 26, 2015 2:35 PM To: [email protected]<mailto:[email protected]> Subject: [msmom] RE: OpsMgr 2012 R2 Architecture Question Wanted to add - a SQL standard license is included in System Center licensing, so there should not be much additional cost in scaling these out - except for additional hardware or VM costs. Lastly, the sizing spreadsheet shows the web console collocated on the reporting server, which is a bad idea and I never recommend that. I always recommend installing that role on management servers, otherwise you will struggle with NTLM auth sign on issues. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey Sent: Monday, January 26, 2015 2:19 PM To: '[email protected]' Subject: [msmom] OpsMgr 2012 R2 Architecture Question Hello everyone. I'm new to SCOM and we currently have a hybrid MOM 2005 and SCOM 2007 R2 environment. I've gotten so far as to recreate all MOM alerts in SCOM so we can finally begin decommissioning our MOM servers. However, I am now turning my eyes towards OpsMgr 2012 R2 and have a couple questions. I have reviewed Microsoft's TechNet articles (link here<https://technet.microsoft.com/en-us/library/hh298610.aspx>) on their Distributed Deployment and I am wondering if the Operational DB can be on the Management Servers? In the diagram from the link above, the Management servers only hold the management role while the operational DB looks to be clustered between two additional servers. I was thinking of the following for our design, but not sure if it's really possible: Our site is ~600 servers and ~200 Network devices: 2 Management servers for agent-based monitoring (w/ operational DB on the management server[s]) 2 Management servers in a resource pool for network device monitoring 1 Data warehouse server Not sure if attachments are allowed, but I have attached the diagram I designed, but again, I'm just not sure if the operational DB can sit on the actual management servers or not. I saw Microsoft's "all-in-one" single server design for testing, which is why I figured the Operational DB *can* sit on the management server(s), but wasn't sure if I'm missing potential pitfalls of doing that. We aren't trying to cut corners, we merely want to avoid an increase in the number of VMs/SQL instances unnecessarily. Thank you for your time. -Geoff Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you. Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you. Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you. Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you.
