Pages

Tampilkan postingan dengan label DataCenter. Tampilkan semua postingan
Tampilkan postingan dengan label DataCenter. Tampilkan semua postingan

Minggu, 03 Maret 2013

Look inside the Backblaze data center and its Pod 3.0 architecture


Takeaway:  Takes a look at the architecture of an online backup service. How do they offer storage at such competitive prices? Here are some of the building blocks.
Have you ever wondered how some online backup companies can afford to provide the services they provide at what seem to be insanely low prices? One company - Backblaze - has, for quite some time, made their hardware specifications freely available. This has allowed those requiring mass storage to rely on a proven architecture that’s used every day to support a profitable business.
Backblaze recently released version 3.0 of their Pod architecture, which sports a whopping 180 TB of capacity in just a few rack units of space and at a cost of less than 6 cents per gigabyte. That 6 cents per gigabyte includes all costs for the storage chassis, 45 x 4 TB hard drives, and all of the components and electronics that make the solution work its magic.

Figure A

Pod 3.0
How do they do it? First of all, Backblaze has spent an incredible amount of time testing and validating every part that goes into their Pod architecture. They do so in both lab and real world, mission-critical, customer-facing environments. As such, the company is an authority on specific parts and whether or not parts work or don’t work. For example, in Pod 3.0, Backblaze recommends the use of a specific brand of SATA cable. For many, a SATA cable is a SATA cable, but for a company like Backblaze, a faulty SATA cable can be a really bad day for a customer, so everything is tested.
Perhaps the most important part of the Pod, the chassis has undergone some refinements in Pod 3.0. It’s a known fact that physical vibration can be a performance killer. Any unexpected movement of a hard drive read or write head requires that drive to spin back around in order to correct the issue. With Pod 3.0, Backblaze has made improvements to the chassis with an eye toward reducing the vibration of the chassis. To that end each row of 15 drives now includes its own anti-vibration assembly intended to address this issue. In addition to helping to keep performance steady, reducing drive vibration can improve disk failure rates.
All told, this 180 TB behemoth costs just under $11,000 to build with 4 TB hard drives. A 3 TB hard drive version yielding 135 TB of raw capacity can be built for $7,567. Backblaze explains that hard drive prices have remained relatively high over the past couple of years, so storage costs are not dropping as they once were, although with the introduction of 4 TB drives, the company is able to squeeze more capacity into a single unit, which provides more storage for less power. In that way, the company can somewhat reduce costs with Pod 3.0. In fact, Backblaze even provides these figures: with 3 TB drives, the company’s cost for the storage is 63 cents per terabyte per month on a full-rack basis. With 4 TB drives, this cost plummets to 47 cents per terabyte per month. If those numbers appear too low, they aren’t. That’s the amortized cost of storage for Backblaze on a monthly basis. The company estimates that the lower ongoing cost for the 4 TB drives means that the more expensive up front costs are recovered in around 5 months.

Figure B

For me, one of the most impressive aspects of the company is their willingness to openly share their hardware specifications and cost figures. To that end, if you jump to Appendix A in this blog post, you will find a comprehensive list of parts that comprise the Backblaze Pod solution. Bear in mind that Backblaze enjoys some significant economies of scale with regard to procurement, so your own cost may be a bit higher if you decide to try and build one on your own.
From a performance perspective, Backblaze’s services are certainly designed to maximize capacity. Data trickles into Backblaze’s data centers and traverses the storage infrastructure. As you may imagine, there is significant write traffic and read traffic increases when a customer needs to recover a system. Backblaze is focused on providing very inexpensive but reliable backup space for their customers and they do it well with Pod 3.0.

Sabtu, 02 Maret 2013

First look at grid storage with Gridstore


Takeaway: There is no shortage of new and different ways of housing data today. In this blog post, IT pro Rick Vanover takes a look at one of the new grid storage architectures.
Last fall, I first came into contact with grid storage. This approach of adding nodes dynamically to a storage pool with a low entry cost and low incremental costs is one that I find compelling. I recently had a chance to play with the Gridstore series of storage products, and it is a different way of doing storage.
That’s a good thing, however. As it turns out, this is a very easy-to-use storage solution that really anyone can handle. The Gridstore nodes start in a configuration of at least three nodes, and can dynamically add nodes as performance and capacity dictate without the upfront investment.
With the first three nodes, the configuration goes over multicast Ethernet for easy discovery and then specific network configuration can be set subsequently. This is all done through an MMC application in Windows, and was quite intuitive. The configuration interface is shown in Figure Abelow:

Figure A


This interface is pretty straightforward to use, and each computer that has the Gridstore software installed on it can be created a vStore, which is analogous to a volume and will inventory as locally attached storage (though it is accessed over the Ethernet network).
The data profile of this virtual storage grid is distributed across the present nodes, and nodes can fail (an important protection element!) as more nodes are added. In the 3 node example, one node can be accommodated as failed.
To see the data distributed across all of the nodes of the grid, inside the MMC console you can see performance of each node and of each node compared to each other. This can be a good way to ensure that all nodes are performing well, and they all should perform roughly equally. If not, this may be a sign of incorrect network setup. Figure B shows the performance view:

Figure B


The interface of this tool is quite easy to use and I appreciate the dynamic aspect of provisioning storage in this case. I don’t know about you, but for some data profiles, we don’t always know what we will need. One good example in this category is disk-based backups.

Rabu, 20 Februari 2013

How to add roles to a Windows Server 2012 computer

Takeaway: Iillustrates the steps to adding roles to servers in Windows Server 2012.

Windows 2012 has brought with it some small changes and some big changes. With it, Microsoft has also tweaked what have become some common processes. Even the basic items, such as adding new roles to the server, have undergone some changes. In this article, I’ll get back to basics and provide you with a look at the way that you add new roles to servers in Windows Server 2012.
As shown in Figure A, the process kicks off from the newly revamped Windows Server 2012 Server Manager. To add a new role, from this window, go to Manage and choose Add Roles and Features.

Figure A


Begin the process of adding a new role to Windows (click to enlarge images)
The first screen you see provides you with some background advice that you should read before you continue. If you don’t want to see this screen each time you add a role, select the check box next to Skip This Page By Default. Click the Next button to continue.

Figure B


The Before You Begin page provides you with preliminary information
Windows Server 2012 breaks roles down a bit more than was done in previous versions of Windows Server. In Figure C, you can see that there are two options. First, you can add a simple server role, such as the IIS role. Or, you can choose to deploy Terminal Services/Remote Desktop Services roles by choosing the Remote Desktop Services Installation option. Click the Next button to continue once you’ve made your selection.

Figure C


Choose your installation type
Another change that has come to the Add Roles and Features Wizard is the ability to deploy roles and features to both the local server as well as to other Windows 2012 servers. This is particularly useful when you have a lot of Server Core deployments and want to use a GUI to deploy roles.
On the screen shown in Figure D, you can choose a server from the pool of servers - I don’t have additional servers in my pool right now -or you can choose to add the role to a 2012 installation on a virtual hard disk. Once you choose the server, click the Next button to continue.

Figure D


Choose the server you wish to manage
Next up, you will see a screen that will look somewhat familiar, depending on your experience with previous versions of Windows. From this screen, choose the role or roles that you want to add to the server.

Figure E


Choose the roles to add to the server
If the selected role requires additional tools or services, a window will pop up that shows you the additional services that are required to support the role. Click the Add Features button to allow these features to be added (Figure F).

Figure F


Additional features are needed to support the selected role
Next, you’re asked to choose Windows features that you may wish to add. In Figure G, you can see that some features are already installed; they’re grayed out. If you want to add features, select them and then click the Next button to continue.

Figure G


Choose the features you wish to add
Some roles have additional configuration options or services that can be included with the installation. At this step of the process, you can choose which options and services need to be included to meet your needs.

Figure H


Choose the additional services you need to support this role
Finally, you will be presented with a summary page that confirms the selections you’ve made. You will also be asked whether or not the target server can be restarted once the roles and features have been added.

Figure I


Do you want to allow a restart?
And that’s it! You will be presented with a status screen that shows you how far along the installation has progressed, but when that’s done, the roles and features will be installed on your server.

How to configure Hyper-V VM boot order

Takeaway: How a Hyper-V VM boots up will dictate a lot, especially if optical media are interchanged. IT pro Rick Vanover shows a few ways to manage boot order for Hyper-V virtual machines in this post.
Hyper-V virtual machine boot order sounds pretty straight-forward, until you need something that is not the default. A virtual machine in Hyper-V will boot from CD/DVD (or mapped .ISO files), optical drives, IDE (fixed local disks), next network services (PXE) and finally, virtualized floppy media. For most Hyper-V setups, this is fine. But what does one do when the boot order needs to change, and it may need to change en masse?
That’s when the virtual machine’s properties can be changed for the boot order. Figure A below shows one Hyper-V virtual machine having the IDE device (VHD / VHDX hard drives) being moved up to be the leading boot device:

Figure A


This is good for situations where users may map their own media, which may include bootable elements (like a recovery environment). Changing the settings in Hyper-V Manager are good for a one-off change (especially if it is sent to a template/library); but not the best situation for a large scale change.
For changing multiple virtual machines’ bootable behavior at once, PowerShell becomes the way to do it. Making that same change in PowerShell is actually quite easy. Using the Get-VM and Set-VMBios commands, this change is made on a per-VM basis. From Figure A, the DLD-2008R2 VM will have its boot order to put IDE first; the following PowerShell script will do this change (as well as query the boot order before and after the change):
get-vm DLD-2008R2 | Get-VMBios
get-vm DLD-2008R2 | Set-VMBios -StartupOrder
@("IDE","CD","LegacyNetworkAdapter","Floppy")
get-vm DLD-2008R2 | Get-VMBios
If this script is to apply to all VMs inventoried on a host (the only catch with PowerShell and Hyper-V Manager in changing the boot order is that the virtual machine does have to be powered off), the following PowerShell script can be used:
get-vm * | Set-VMBios -StartupOrder
@("IDE","CD","LegacyNetworkAdapter","Floppy")
Running this script is shown in Figure B below for a single VM.

Figure B


Click to enlarge.
Changing the boot order in Hyper-V is actually quite easy to do, especially since it is done from the management layer of the hypervisor, rather than in the virtual machine. This TechNet blog post talks a bit more about the Set-VMBios command from PowerShell.
Do you find yourself changing virtual machine startup options? If so, what situations make you need to do this? I’ve done a few but am curious what you are seeing. Share your experiences below.

Senin, 18 Februari 2013

Make sure BYOD doesn't mean Bring Your Own Disaster


Takeaway: Scott Reeves takes a look at the security gaps that BYOD can open up for the corporate network. Create a policy and cover these basic points.
The idea behind BYOD is that users can use a personal device such as a tablet for both personal and business use. As you can imagine, the scenario of users bringing in their own devices to connect to a corporate network gives visions of malware and /or other nasties spreading through the corporate network. This has led to some people dubbing BYOD as “Bring your Own Disaster”. As with many areas in IT, however, you can set some rules that should minimize the security risks of BYOD.

Why BYOD?

Many users now have devices that they are comfortable using. For example, some users may have a Mac Book Pro, a Linux notebook, an iPad, or a smartphone. BYOD can assist a company by achieving savings in outlay on IT items such as laptops or PCs. Staff can use their personal devices, and by so doing, can also be more productive. The growth in BYOD has been fuelled by the growth in tablet computers and smartphones. It is expected that these devices will represent the majority of all personal devices used by personnel.

Security issues

BYOD does bring with it a host of security issues. Malware and eavesdropping (in the case of using public Wi-Fi) are two possible risks. What we will do in this post is to take a look at some of the preliminary steps required for implementing BYOD. Ideally, a policy document on BYOD should be created, and all staff members should be able to access the policy document.

What devices are supported?

A good starting point for BYOD is: what sort of devices should be able to access the corporate network. Following on from this, what sort of operating systems should be supported on the corporate network, and potentially what version(s). The supported devices will in some respects be driven by what applications are required. A Windows 7 application, for instance, may have no equivalent on an iPad. If it is a critical application, then personnel won’t be able to use an iPad on the corporate network until the application is ported to iOS.

What levels of access are permitted?

Some users may be allowed different access depending on their job function. As an example, sales people may use tablets more than standard laptops/PCs. Support staff may use laptops or tablets when on the road.
What this may mean is that support staff will have intrinsically different requirements for access compared to say, sales. Support staff may (for example) require access to in-house knowledge bases, or to other databases. Sales personnel may only require intranet, email and messaging access.

What corporate applications are required?

The next aspect is what applications need to be installed on the user’s device. Depending on the user groups, some users may have access to differing levels of data. As mentioned above, support staff would generally need to access support databases, whereas other staff may only need access to email and the corporate intranet.
In addition to deciding what corporate applications are required, you may need to decide what sort of antivirus protection can be installed on a device. Other applications that may need to be installed are email clients, messaging, and Virtual Private Network software (for staff that are likely to be working remotely).

Using a VPN for remote access

In particular, using a device on public Wi-Fi networks is probably the biggest headache. This is where a VPN solution is required. A VPN will require authentication, and will encrypt data. For this reason, a VPN client must be amongst the list of software solutions installed on a user device. There are a number available; the ones I have used are the Cisco VPN client and its successor, AnyConnect.

Set passcodes

There is an area that is overlooked many times on tablets and on smartphones: set a security code. This is possibly the most important part of BYOD, particularly for personnel that are likely to be using public Wi-Fi networks. Theft of a device that has no passcode may still not let a casual user in, but having a passcode should be the primary level of defence.
In summing up, your BYOD policy needs to cover:
  • What types of devices are permitted access, such as Android, iPad, MacBook, Wintel, and what version of the operating system is required.
  • Secondly, decide which access level your different groups of users require.
  • Third, decide what applications are required for a user.
  • Fourth, and most important, a VPN is required for personnel likely to be using public Wi-Fi networks.
  • Finally, educate users about the importance of setting passwords and passcodes. These guidelines should go some way to maintaining the security of corporate data.

Senin, 06 Agustus 2012

Disable guest DHCP with Hyper-V DHCP Guard

Takeaway: Rickatron shows a nice front-side technique to prevent a rogue DHCP server in your Hyper-V infrastructure.
If you have any amount of test or development infrastructure, a rogue DHCP server has surely shown up. While I’ve been lucky to never have it show up on a production segment, I’ve seen many a network administrator track one down and shut down a port to try to find the offending virtual machine.
As it turns out, virtual machines can be hard to find as they have different MAC address formats and may move around to different segments if on a laptop or host with migration technology enabled.
With Hyper-V R3, Hyper-V administrators can make their virtual machine libraries disallow DHCP server packets to be sent from the host by default. The DHCP guard feature sets this property at the virtual machine network configuration. This step is shown in Figure A:

Figure A

The selected area has the DHCP guard option selected.
The selected area has the DHCP Guard option selected.
There are a number of ways to tackle this problem, including switch configuration and possibly arcane server administrative practices. However, with any test or development capacity, the rules seem to lighten as requirements in these environments differ from their production counterparts.
One of Active Directory’s keystone features is authorization for DHCP servers. Given that Hyper-V is quite aware of Active Directory and other Windows environments, this works well in the grand scheme of things to protect against the unauthorized DHCP advertisements.
DHCP Guard is an example of a granular setting that should be set as part of the virtual machine library creation process. This is for both server and client operating systems. Should a user install something like VMware Workstation, Oracle VM VirtualBox, or another type II hypervisor, additional operating systems (including a DHCP server) could be added within.
Do you see value in this configuration option? I do! Would you configure your library virtual machine to use this setting? Share your comments below.

Kamis, 17 Mei 2012

Use vSphere Client to determine number of paths to a datastore


Takeaway: Ensuring that storage is properly provisioned is a key to a successful vSphere installation. Rickatron shows how to check the active number of paths for a datastore in this blog.
When it comes to designing storage for virtualization, there is one important step that happens in every environment, it seems. It is the whiteboard step where each ESX(i) server is drawn up to have two or more HBAs to two or more different switches to a storage controller with two or more interfaces. This also occurs with iSCSI with multiple initiator interfaces going to different switches to the storage controller. This is shown in Figure A below, and can be tweaked and changed in many ways with different storage products or network configurations:

Figure A


The design up front is very important, but it is also critical to check inside of the ESX(i) host to see that the expected number of paths are present on the hosts. But even more importantly, you want to see if any are listed as broken. Within the vSphere Client, we can easily see the status of the paths. Click on the host and then the configuration tab, select a datastore, and the path information is shown. Figure B is an example of a host with two paths to a datastore:

Figure B

Click to enlarge.
But the catch here is that each host has its own path configuration. And while the datastore properties on one host may be correct, there is no guarantee that the next host in the cluster is configured as you expect it to be. The properties of the datastore can show which path is active and change the multipathing policy, but this is a configuration that is live for each host in a cluster.
The vSphere Client makes it easy to take a quick look at a host’s configuration for paths to a datastore. What tricks have you used to check to ensure that each host has the requisite and planned number of paths to datastores? Share your comments below.

Sabtu, 12 Mei 2012

Finding log events for Hyper-V on Windows Server 2012


Takeaway: Hyper-V logs events for virtual machines, but the locations and processes may not be intuitive. Rick Vanover shows you where to look for logging info in Windows Server 2012.
In Hyper-V Manager for Windows Server 2012 (as well as Windows Server 2008 R2 and the base release), there isn’t much in the way of a tasks or events history for the VM, so I’ve always found it to be a challenge to find out “what happened” in the way of logging events.
Luckily, Windows logs Hyper-V events just like it does other roles — in the Event Viewer! So, we can even search and filter these events. Newer versions of Windows also now include categorized logging sections, which is where I will start in this blog.
In the Event Viewer, I’m used to looking in the “Windows Logs” section to find either the application, system, or security log event I’m looking for. But starting with Windows Server 2008, we were able to have the component logging sections, also. This will really help us with Hyper-V. In the Event Viewer snap-in, navigate to Applications and Services Logs | Microsoft | Windows, and there lie a number of Hyper-V categories. Windows Server 8 displays nine sections with the current beta. This area of the Event Viewer is shown in Figure A:
Event Viewer - Hyper-V sections
Event Viewer - Hyper-V sections (click to enlarge)
In this area of Hyper-V logging, we can see specific Hyper-V events. One that is worth noting is the task associated with creating a new virtual disk file (Hyper-V .VHD). This event is logged in the Hyper-V-VMMS | Operational section of the Event Viewer and is an Event ID 27311. Figure Bshows an example of the .VHD file being created and logged:

Figure B

Hyper-V event showing a VHD file added to a VM on the host.
Hyper-V event showing a VHD file added to a VM on the host
This section of the Event Viewer has a number of the relevant aspects of Hyper-V logging. A certain amount of logging is done within the guest VM, but that generally is not related to host activities. The good news is that in a pure Windows world, connecting those two environments is quite straightforward with enterprise frameworks such as System Center Operations Manager.
How do you go about logging host events on Hyper-V? Do you exclusively use the Event Viewer? Are more tips up your sleeve? Share your Hyper-V event logging tips below.

Kamis, 10 Mei 2012

Use ExDeploy to help plan your Exchange deployment

Takeaway: Scott Lowe illustrates how the planning and deployment tool, ExDeploy, helps you get ready for your Exchange 2010 upgrade.

Planning an Exchange 2010 deployment can be a lot of work. There are a number of moving parts that must be considered, particularly when migrating from an earlier version of Exchange. Moreover, there are different ways you can choose to deploy Exchange 2010.

In order to help you in your deployment efforts, Microsoft has developed a tool called ExDeploy, which can help you in a step-by-step way achieve your Exchange goals.
To this end, you can use ExDeploy for the following scenarios:
  • On-Premises Only
    • Upgrade from Exchange Server 2003
    • Upgrade from Exchange 2007
    • Upgrade from mixed Exchange 2003 and Exchange Server 2007
    • New installation of Exchange 2010
  • Hybrid Deployment (On-Premises + Cloud)
    • Exchange 2003
    • Exchange 2007
    • Exchange 2010
  • Cloud Only (Exchange 2010 only) (Not quite as complete)
To run ExDeploy, visit the full site, and make sure you have Silverlight installed. Since Silverlight works on both Macs and PCs, you can use ExDeploy from either platform; it worked equally well on both of my machines.
You are greeted with a screen asking you to choose the kind of deployment you intend to undertake: On-premises, Hybrid or Cloud (Figure A).

Figure A


Choose your deployment type
Once you’ve selected a deployment type-I chose to do an on-premises deployment-you’re asked to provide a bit more information so that the tool can provide you with the best possible guidance. In my case, I’m asked to decide what kind of on-premises deployment I wish to undertake. As you can see in Figure B, the tool provides guidance for upgrades from Exchange 2003 and/or Exchange 2007 as well as for brand new Exchange 2010 deployments.

Figure B


ExDeploy provides guidance for a broad range of scenarios.
Next up, depending on the options you’ve already selected, you’re asked a series of questions. The questions are tailored to your selection. In Figure C, you can see the questions that are asked when the intent is to perform an on-premises upgrade deployment from Exchange 2003 to Exchange 2010. In Figure D, you can see the questions that are asked when you choose to perform a hybrid deployment.

Figure C


The questions help the tool provide more exacting guidance. (click to enlarge)

Figure D


You’re asked a few questions for a hybrid deployment. (click to enlarge)
With the interrogation out of the way, this is where ExDeploy really shines. Based on the information you’ve provided, ExDeploy provides you with full deployment guidance for the scenario you’ve intended and with regard for the answers you’ve provided to the questions. Figures E and F give you a look at two different deployment plans.

Figure E


A full deployment plan for an on-premises deployment

Figure F


The deployment plan for a hybrid deployment (click to enlarge)
In both Figures E and F, you will note that you’re provided with a checklist consisting of step-by-step tasks and objectives that must be met in order to successfully deploy Exchange in the desired configuration. For each task, you’re given an estimated completion time, helping you plan just how long something should take and, in most cases, you’re provided with PowerShell commands that will help you achieve your goals. You’re also given guidance as to how you will know if you’ve properly completed each task so that you don’t accidentally misconfigure something that affects you later.

Personally, I’ve found the tool to be incredibly helpful in planning Exchange 2010 deployments. It’s not perfect, though; some availability mechanisms and advanced topics such as using Database Availability Groups are not covered, but you’re given 90% of the answers.

Just as I don’t depend solely on the Exchange mailbox calculator for sizing Exchange environments, neither do I depend solely on ExDeploy for my planning. That said, I do use both tools as a part of my larger planning and deployment efforts.

System Center 2012: Tighter integration between private cloud components

Takeaway: New integration between System Center 2012 Operations Manager and Virtual Machine Manager enhances support and management of private clouds. John Joyner describes the new features.
Microsoft’s simultaneous release of System Center 2012 versions of Operations Manager (SCOM) and Virtual Machine Manager (SCVMM) put on display some new integration features.

The new features support the cloud-centric theme of System Center 2012 as a complete platform to deploy and support the private cloud. In particular System Center 2012 Operations Manager makes management of private clouds — created by SCVMM and optionally deployed by App Controller (a cloud management component new with System Center 2012)-achievable in a service provider oriented environment.

There has existed a deep integration between SCOM and SCVMM in their previous and current releases (SCOM 2007 R2 and SCVMM 2008 R2). This integration has leveraged the alerting, performance tracking, and reporting features of SCOM effectively, and made the System Center suite a more attractive solution. In the newest generation, the integration is tighter, easier to enable, and less intrusive than before. Since System Center 2012 customers will own the license to install and use both SCOM and SCVMM for private cloud management, this integration should be a common experience for many organizations.

Enable integration on the SCVMM side

Prerequisites to enable the SCOM-SCVMM integration in System Center 2012 are not so complex. You need to install the management consoles of both components on the respective servers, i.e., the SCOM console on the SCVMM computer and the SCVMM console on the SCOM management servers, in particular, the management server that holds the RMS emulator role. You also need to have a Virtual Machine Manager Connection Account with some administrative rights for SCVMM to use, pre-created in your domain. Access to a SQL Server Analysis Services (SSAS) instance, including the rights to create a new SSAS database, are optional if you want to use some forecasting analysis reports in SCOM.
To enable the integration on the SCVMM side, navigate in the SCVMM administration console to the Settings | System Center Settings node, right click on the Operations Manager Server object in the Settings section and select Properties. You will provide the name of the SCOM RMS emulator and the SCOM management group name. You can also elect to enable additional features like Performance and Resource Optimization (PRO) and Maintenance Mode Integration with SCOM. Figure A shows the configuration of an SCVMM instance connected to SCOM.

Enabling SCOM to SCVMM integration in System Center 2012.
After you have performed the integration, if you have elected to use the PRO feature, PRO Tips will appear when thresholds or conditions arise that trigger PRO events, such as resource exhaustion of a guest VM on a particular host. PRO Tips are selected for automatic implementation (self-healing) in a granular setting at the host cluster level in SCVMM. Figure B shows some PRO Tips in the SCVMM pop-up window (which can be selected to not pop up). PRO Tips that occur when automatic implementation has not been selected await optional and manual implementation here.

PRO Tips awaiting implementation or dismissal in the SCVMM console.

SCOM integration performed transparently

A time saver and nice engineering feat is that the integration step in SCVMM performs all the necessary work to complete the integration on the SCOM side. The management packs for SCVMM are automatically and remotely imported into the SCOM management group by the SCVMM server. Views are created in the SCOM Monitoring space and reports become available in the Reporting space. Credentials for the Virtual Machine Manager Connection Account are automatically and securely distributed to the SCVMM server and each SCOM management server (as a RunAs account ).
SCOM is immediately ready to use as a decision and display console for private clouds deployed by SCVMM. Figure C shows the SCVMM views in the SCOM console, focused on the VM Usage Count for the last twelve (12) hours in a particular private cloud, in this case steady at three (3) VMs. PRO Tips appear in their own top-level view folder (not shown). The unit of “cloud” for management across SCOM, SCVMM, and App Controller is consistent and matched in the views and reports, which are available on a per-cloud basis.

Private Cloud Virtual Machine Count Performance view in the SCOM console. (click to enlarge)
The new reporting integration between SCVMM and SCOM is particularly praiseworthy. SCOM reporting leverages the wealth of metric data collected by both SCOM and SCVMM to produce valuable reports for cloud billing and capacity decision making. Among the ten (10) reports in the integration package, the Chargeback report looks to be really useful for service providers. Figure D shows this report for consumption-based charges on a four (4)-VM private cloud for twelve (12) days. A nice feature is that you can play “what if” with live data by manipulating the costs per resource unit in the report parameters.

The Chargeback Report in SCOM produces cloud billing documents based on hourly consumption. (click to enlarge)
Note: The Twitter hashtags (#scom and #scvmm) for components SCOM and SCVMM reflect a community consensus to use the System Center (#sysctr) hashtags consistently as acronyms.