Tag Archives: Matrix

HP CloudSystem Matrix Part 3: manage your resources

This post is the last of a series of three that explain the concepts and technologies that are used in HP CloudSystem Matrix. The first one was about creating a CloudMap. The second one was about how to deploy a complete IT service automatically.  This post is about the management of the resources (servers, storage, networking, software) that can be used and shared as a pool across several services.

The idea behind CloudSystem Matrix is relatively simple : the whole environment should be as easy to manage as possible.

This starts first with the firmware management. All c-Class enclosures have a defined firmware level according to their Matrix version. This means that the server firmware (HBAs, BIOS, iLO, NICs, etc.), the interconnect modules (HP Virtual Connect Flex-10, Fibre channel or FlexFabric) as well as the Onboard Administrator (the enclosure management processor) have a defined firmware level that was tested and qualified to work together in the best way. Given that HP implementation services take care of the firmware deployment, the administrators don’t have to bother about it.

What can be managed by CloudSystem Matrix ?

The physical servers to be deployed must be HP blades (ProLiant x86_64 or Integrity Itanium servers).The reason for that is that we leverage the capabilities of Virtual Connect to apply network profiles (MAC addresses and WWN) and this technology is available on our blade servers.

However, the virtual machine hosts (VMware, Hyper-V, or HP-UX Integrity Virtual Machines) can be HP blades, HP rack-mount servers (Integrity and ProLiant) and even third-party servers (Dell PowerEdge 2000 series, e300 series , IBM System x servers 6000 series, r800, r900, x300 and x3000 series and IBM blade GS and LS servers) making CloudSystem Matrix probably one of the most open cloud solutions on the market.

In order CloudSystem Matrix to work, the management server needs to discover and manage the targeted equipment. The management console of the VM hosts, the management processors and the interconnect modules must be recognized by the so-called CMS (central management server). It will recognize the presence of the Virtual Connect domain group (which manages Virtual Connect for multiple enclosures) and will put the servers not used as VM hosts as possibly usable for physical deployments.

As soon as the CMS has discovered the equipment, the administrator can use its console on the CMS to create and assign pool of resources to different users.

From this management console, the administrator can manage all the elements provided to both IT architects and business users.

What IT architects need to create their cloud maps first is network connectivity. The VLANs at disposal to the IT architects are the Virtual Connect vNetworks. The administrator provides them to the IT architects using the tab “Networking” on the management console.
There, the CMS communicates with Virtual Connect Enterprise Manager and retrieves all available networks. Each network must then be configured to provide information about the range of IP addresses usable, if the IP address is allocated via DHCP or if the CMS allocates it from its pool of fix addresses.

As soon as a server is put in the enclosure and is managed by Virtual Connect Enterprise Manager, it appears in the “Unassigned” pool of resources. From here, it can be moved to a pool of resources that can be dynamically assigned to a business user. This user will only see the pool of resources that are allowed to him in his self-service portal.

In CloudSystem Matrix, the group of Administrators has all rights, hence they can see all services currently running. The business users can also FlexUp his service by adding either disks or servers to the currently running service, in case, for example, that an unexpected load occurs on the service.

From this console, the administrators can see all items that can be deployed via CloudSystem Matrix: network items, operating systems (retrieved from RDP job, Ignite depots and golden images as well as Hyper-V and VMware templates), storage pool entries, as well as servers. They can control all requests as well as currently deployed services. I will write a new post to explain exactly how the storage provisioning works.

All in all, this third post explained how administrators can, from a single point of control, manage their resources and put them at disposal to the users. The CloudSystem solution is a complete solution that can help IT departments reduce their TCO of up to 56% compared with traditional rack-mount servers. I have already deployed it for customers and must say that many of them are really impressed of the power of the overall solution.

How to provide SMI-S connectivity via Command View EVA without HBA ?

What is SMI-S ? SMI-S is a standard communication protocol based on WBEM that helps manage heterogeneous storage arrays in the same way. Say you want to create a disk of 50GB on a HP EVA and an EMC Clariion, you will send the same SMI-S request to both and the arrays will translate the command to create the disks.

As Command View provides SMI-S connectivity out of the box, it should be easy, right ? Wrong ! (at least in my case).

Usually, you would have a fiber channel host bus adapter connected to the Command View server. However, my CV server does not have one. Also,  the EVA ABM (Array-Based Management), an embedded tool that helps manage EVA arrays, in my case a 4400, does not provide any SMI-S connectivity. The Command View documentation nonetheless states that “If you have layered applications requiring HP SMI-S EVA, you can install the HP SMI-S EVA component on any server that is either connected to the EVA/SAN or has access to HP Command View EVA via Ethernet.”

The hard task was to find how to make this work.

SMI-S provides a utility called discoverer.bat, located in C:\Program Files (x86)\Hewlett-Packard\SMI-S\EVAProvider (yes, Command View only runs on Windows…)

Execute it

Press 1 to add the IP address and the credentials of the ABM.

Verify that the ABM was successfully discovered

Everything ran fine and now, I can discover my array through the Storage Provisioning Manager (SPM), a technology designed to present and deploy storage LUNs automatically as part of BladeSystem Matrix. I will write an entry about it later on !

HP CloudSystem Matrix Part 2: deploy your application

This post is the second of a series of three that will explain the concepts and technologies that are used in HP CloudSystem Matrix. The first was about creating a CloudMap. This post is about the provisioning and automated deployment of an IT application. In a third post, I will address how to manage the pools of resources !

CloudSystem Matrix is a private cloud solution that aims at speeding the deployment of applications through highly automated technologies and integrated processes.

After we have created and published our cloud map, we have provided our business users all the information they need in order to deploy the application they require to execute their company’s strategy.

In order to do so, the user logs in to the self-service portal.

As you can see, the home page shows which resources are put at disposal to the user, as well as the current service consumption. We see that five physical servers, out of the six at disposal, as well as two virtual machine hosts are in use as part of a service deployed by the CloudSystem Matrix. By clicking on the “Templates” tab, we can access the list of templates which are published and which the user has the right to deploy. Remember the SAP 2-tier template we created in the first part? We have published it, hence we find it back here. That the user has created the template or not, doesn’t play a role as long as he has the right to use it.

By clicking on the template, the business user can display the details of the service: the layout of the network, the price, as well as the notes entered by the creator of the template, etc. In order to deploy the service automatically, he will click on the button ‘Create service’.

The user now has to enter a service name (for instance “SAP 2-tier John Smith”), the hostname completion (remember the need for a hash sign in the first post ?), an email -to contact the service requestor-, a start date and hour at which the service will be deployed, an end-date, at which the service will be rolled back, and finally, a pool of resources, from which the resources, such as servers, storage and networking, will be picked from. Final step: he clicks on “Submit”, and here we go !

The request is sent and the activity which is happening behind the scenes is displayed: the resources are reserved from the pool of resources. The software makes sure that the pool can accommodate the need indicated in the template. We can see here that four servers, four IP addresses, three networks and four boot disks are requested. CloudSystem Matrix will pick from the pool of resources the servers that meet at least the requirements of the template and will pick from storage disks (LUNs) that are already presented to WWN (worldwide names) and also meet the size indicated.

We see here that CloudSystem Matrix also integrates nicely into the user’s processes: the request above is paused, because an administrator (or an IT manager or anyone else who should take this decision) must give his approval, so that the deployment can continue. A Request for Change (RFC) could also be triggered at this point in time with tools such as HP Service Manager or BMC’s remedy. The teams using these tools will just have to accept the request and the deployment will go on.

We see here that the administrator granted the authorization to deploy this service and that the allocation process has started. The requested resources are then provisionned. The physical servers are reserved and a custom HP Virtual Connect profile is applied to them. This means that we are applying one ore more MAC addresses for the network, which will be connected to the VLANs we need, as well as one or more WWN for the storage, to which disks are already presented. The zoning of the storage was already prepared, so that after the WWN is attributed to the server, it can install the operating system as well as the application straight after the VC profile was attributed.

Taking a look at the Onboard Administrator, the HP BladeSystem enclosure management processor, the server loses the “i“-icon, which means that the server has now a Virtual Connect profile

On the screenshot above, we can see “Provisioning the logical server” (either physical or virtual) and, finally, “Activating logical server”: the ProLiant or Integrity server is now starting.

If VMware or Hyper-V virtual machines were to be deployed, CloudSystem Matrix would pick the right template, clone it, provision it, and finally adapt it according to the needs of the cloud map. If HP Integrity Virtual Machine were deployed, the host would be contacted vis SSH, it would create the VM and deploy it with Ignite UX either through normal package deployment, or via a golden image, a concept similar to the VMware/Hyper-V template.

We see above that the Integrity server starts, it then boots from the network (since the disks we have presented are empty) and that Ignite UX detects a deployment request from the client.

All the deployments methods (Ignite-UX,  HP RDP, HP Server Automation, etc.) and CloudSystem Matrix can communicate with each other: the deployment server confirms to the Matrix operating environment that the deployment request of a given client was received. This is acknowledged by the management server which indicates it to the user.

Finally, after the operating system is deployed, the application is installed through the execution of a workflow (it will be the subject of another blog post in the future).

Although I discussed the technical details of what happens behind the scenes, the business users, when they make a request, can see a completely abstract high-level view of what is going on. They don’t need to know the details, they just want to know if the application was deployed.

On the picture above, the business user sees that everything went well and that his IT service is up and running. What could have taken so much time to deploy, lasted roughly one hour with HP CloudSystem Matrix.

Instead of taking months putting all the pieces together, CloudSystem Matrix orchestrates the provisioning of storage, server and networking, installs the operating system and deploys the application in an automated way, also integrating in the organizations’ processes.

It is a fantastic tool that was already embraced by customers to modernize their IT environments. I have personally helped some of them deploying this solution in their datacenters and they love it. Though it needs a good understanding of key HP technologies (HP BladeSystem, HP Virtual Connect, HP Systems Insight Manager, etc.), the HP services team take care of the deployment of the solution, and the complexity of the infrastructure is hidden to the business users.

In my third and last blog entry for this series, I will focus around managing the infrastructure to fill the different pool of resources and how to present them to the users.