Someday it happens to any VMM fabric owner – host crashed and several hundreds of vms are being rebooted simultaneously creating famous “boot storm” on host and bringing performance down to unacceptable level for pretty long time. So the same happened to me. After the fire was settled I started to think how to prepare better for next crash and one obvious idea popped out – we need to ensure that vms are booted not in same time and ideally based on some priority as I want my fabric domain controllers or SQL servers to boot before wsus server for example. I started to check how I can achieve my goal by changing some policies in VMM. After a bit of investigation I found following facts:
Lets review an example of practical SMA usage for common operational tasks. Usually people responsible for Exchange environments with multiple Exchange servers joined in DAG are interested to know if due to some reason databases are balanced unequally between nodes, lets see how can we inform these guys with status report on it Modern IT world is all about automation, there is no doubt in that, either you automate or you out of serious game, end of story. For a long time there was a pretty good solution from Microsoft aimed to solve a need for central automation orchestration tool - Microsoft Orchestrator. It was doing its job quite well so far so what changed or what will change with release of System Center Service Management Automation (SMA)? |