First insight into SCOM 2012: What’s up next…
There were actually quite some sessions which gave a good preview of the SCOM2012 version which is pre-beta now and will become RTM by the end of 2012.
Until then more and more features will be communicated.
One of the most interesting features actually is that SCOM 2012 will tackle one of the biggest nightmares of all SCOM admins: the SPOF which is called RMS. All SCOM admins will have to admit that at one point or another they faced problems with their RMS which was acting up funny. In SCOM 2007 you are only allowed to run one RMS which is actually a MS which has the Root MS role. The SDK service can only and exclusively run on this machine making it the hart of your SCOM environment.
Your environment is highly impacted when your RMS is down.
The consciences:
- You cannot perform any admin tasks
- All consoles (including web) connect to RMS and will not open
- Product connectors depend on RMS and therefore they can not get info out of SCOM.
- Subscriptions depend on RMS therefore you will not have notifications.
RMS becomes “Management Pool”
Fortunately this is tackled in SCOM 2012 by a new organization of the management servers. RMS which was introduced in SCOM 2007 will be history. In fact all the management servers (MS) will be automatically joined to a management pool which will all have the SDK service running. Because all the MS have the SDK service running they can all perform the task of the old RMS
This has some nice advantages:
- MS can easily be added and removed because there’s a automatic failover between all the MS which are in the management pool
- There’s no need for clustering in the management servers any more to assure high availability of the RMS.
- High availability is now available out of the box!
- MS share the workload over the entire management pool.
The management pool is automatically created when you install the first MS and it will automatically add all MS’s which are installed afterwards.
Pretty cool feature if you ask me 
New network monitoring features
Seems like Microsoft Really beefed up the network monitoring features. There’s a complete new way of discovering new devices which are in your environment. A nice cool feature is the map which is drawn of your network. You can also check which components are in the vicinity of the troublesome device so this can be very helpful in case of a faulty device.
- The network will be drawn in nice topology maps and the monitoring will have some cool gauges / dashboards to make network monitoring much more clean and sleek.
- MSFT plans to support roughly 90, IIRC, vendors out of the box so not much customization needed and more time to tackle the real day to day issues!
- Monitoring includes all the small bits and bolts of your network like Network Port monitoring, memory counters, VLAN health, HSRP health, connection health at end points
SCVMM Dynamic Memory: Do we need it?
Among a lot of new things implemented with the recent SP release for Windows Server 2008 R2 were also 2 nice features for Hyper-V.
Dynamic memory and Remote FX.
This blog post I’ll discuss Dynamic Memory.
Dynamic Memory solves a question a lot of customers (and admins) ask me when implementing an Hyper-V environment.
How many Memory do I have to give my machines to make them run smoothly?
With physical machines it’s rather easy to determine the amount of memory you need. You make an assessment when you buy the machine and order a certain amount of memory for the machine. If all goes well you will never have complaints about out of memory apps. To determine the amount of memory you look into the role of the server and the software manufacturer hardware requirements. You add some more just to be safe and you’re done.
BUT if the server is not using all it’s memory it’s just a waste of memory, money,… You’ll never notice it but this is actually the case for a lot of physical servers. There’s just so many unused memory out there. Why not take advantage of this wasted memory in a virtualized environment?
The same assessment is made for virtual machines.
How much memory do I need to assign to my machine to make it run smoothly and relax as an admin that the virtual machine will be up for the job it’s supposed to do.
There are some common scenario’s which I’ve seen at some customers. It’s more of a company policy to have 1 or more approach(es).
- The trial and error approach: Just give the new virtual machine 1 GB and see whether the customer complains and than add some ram to keep them satisfied. .
- The physical machine approach: Just give all the new virtual machines 4Gb of RAM. I have no clue what’s happening inside with the memory but everybody is happy.
- The common sense approach: The software requirements are 4Gb. I’ll give the server 4GB + a margin of 50% to assure it has plenty of memory. I don’t have a clue whether the app needs all this memory but I don’t care…
If you use one of the approaches above you know in advance how many machines can operate simultaneously on a Hyper-V host because you can do the math.
For Example: If you have a machine with 16Gb of Ram you can run 3 machines with 4Gb and 1 with 3Gb. That’s it…
If there’s one machine which needs more RAM you’ll have to move it to another Hyper-V host or add RAM to the host to keep all the machines (and your customers) happy…
Wouldn’t it be cool to have a feature that dynamically checks whether the memory assigned to a server is still needed and if it requires extra memory transfers memory from one machine to another? Well this is where dynamic memory comes into play…
Dynamic memory will actively manage the memory of the different virtual machines!
So you can do more with the same amount of memory? So…
Yes we need it!
So how does this actually work?
First of all the dynamic memory Driver gathers all the physical memory and adds it into the memory pool. The memory pool consists of all the memory on the machine minus the buffer you specify to keep the Hyper-V host up and running.
This memory pool is than used to distribute dynamically memory to virtual machines whenever they request additional memory.
When you enable dynamic memory you have to make sure the settings below are properly filled in:
Startup RAM: The amount of RAM the machine receives from the DM driver when it boots.
Maximum RAM: The maximum amount of RAM the machine can get from the DM driver.
Buffer: The percentage of Ram the DM driver reserves for the machine to make sure it can handle sudden bursts in workload and temporary needing more memory to cope.
When these options are set. You can fire up the machine and the DM driver takes over the assignment of the RAM to the machine.
How does the DM driver determine how much memory is given to a machine?
The DM driver carefully monitors the amount of the machine needs to operate and makes a memory pressure ratio. This ratio basically is the relationship between the amount of memory the machine currently has and how much it want to operate properly. This ratio can be calculated by the total committed memory in the guest operating system running inside the virtual machine. When the machine asks more memory than there’s in the buffer the DM will supply extra memory to the machine.
How does the DM driver reclaim memory from one machine to give it to another?
This is where the ballooning driver comes in to play. The ballooning driver is actively managing the machines to give out memory back to the pool to be used to give to other Virtual Machines.
There’s a big difference between adding and removing memory.
- The addition of memory is active: It is immediately added to the VM when requested
- The reclamation of memory is passive: Memory is not reclaimed when there’s no need for extra memory in the pool to supply to other VM’s who are requesting additional memory. Unutilized memory is collected every 5 minutes.
The addition of memory is handled by the Synthetic memory driver and is light weight. It does not require any hardware emulation and adds the memory to the machine instantly.
The reclamation of memory is done by the ballooning driver. It’s basically taking the amount of memory requested by the DM driver and reserving it in the virtual machine. It then notifies the DM driver it has captured the memory within the virtual machine. Because the virtual machine can not use this memory anymore it can be extracted from the machine without interrupting it’s service. The amount of memory reclamation is calculated by the ratio which I’ve explained earlier in this post.
The memory is placed back in the pool and ready for use to distribute to another VM who is in desperate need of some additional memory to keep things going.
Because of this dynamic adding and reclaiming memory the amount of total physical RAM shown in the task manager is the high watermark of the memory allocated to the VM since it was booted. You can’t see the balloon size from within the guest—you have to use performance counters in the parent partition.
SCVMM 2008 SP1 now fully supports this new features of Windows 2008 R2 SP1 so you can continue to use your tools to manage your Hyper-v environment.
Next blog post will be about the installation / upgrade of your environment.