Eight things worth considering before building your first private cloud (Part 3 of 3)

TwitterFacebookGoogle+LinkedInRedditStumbleUpon

Read Part 1 and Part 2 of this series.

In this three-part series, we look at what to consider in the early phases of a private cloud project. We already talked about virtualization, automation, self-service, and chargeback. In this last part, we will see how important it is to keep in mind subjects such as monitoring, compliance, backup, and security too.

5. Monitoring (and help desk)

In a cloud environment, not only administrators but cloud users too will want to monitor what’s going on. This means that the monitoring solution (for instance, IBM Tivoli Monitoring) should not only work with the cloud, but also be integrated within the self-service portal so that everyone can follow the health of their virtual machines.

If you plan on supporting the cloud environment through a help desk, you will probably need to feed your corporate Configuration Management Database (CMDB) after every single change (creation, modification, or suppression) of virtual machines. This interface should be planned carefully. This way the help desk will “know” about the actual state of your cloud environment. If you are to host production workloads on your cloud, this step becomes mandatory.

6. Compliance (and patch management)

You have to decide with all the actors, from security to end users, what will be the policy in terms of compliancy checks and patch management with software such as IBM Tivoli Endpoint Manager:

  • Do you need compliance checks?

Whether it is wanted or not, some people are susceptible to violating corporate rules. This is why compliancy checks must be run on a regular basis. These tests need to be defined before implementing the cloud, to show what is possible and what is not from the beginning. And do not forget to plan for a mechanism to alert the virtual machine users!

  • Do you need to enforce policies?

The problem is that, when it comes to patch management, owners of virtual machines will probably be reluctant to apply patches that could break their software. One relatively good compromise is to allow each user to choose between either managing patches themselves or leaving patch management to the cloud administrators, with a different cost for each service, of course.

7. Backup (and recovery)

This is a vast subject because you need to worry about:

  • Backing up your cloud management platform

The same way you back up any virtual machine in your traditional IT is the way you should back up your cloud management platform and have a tested procedure to restore it.

  • Backing up your cloud virtual machines

Provide your users a way to back up and restore themselves virtual machines. This should be a self-service offering, and because storage has a cost, you should see that this space is charged.

Decide what your policy is if you lose a virtual machine: Will you recover it from a virtual machine’s backup? I suggest you make this a manual process (or scripted) because this scenario should not be too frequent.

  • Being able to recover from the major crash of a whole data center

Last but not least is the case of a major crash of the whole data center. In this situation, you will need a clear strategy and carefully plan for it during the early phases of the project. Third-party site recovery tools, depending on the way you plan to use those, might or might not be compatible with all the pieces of your cloud solution.

If you have not already read it, I suggest you look at “Considerations for backup and recovery in cloud” from David Kwock.

8. Security

Last but not least is security: The key words here are “best practices.”

  • Physical security

Even if we are talking about virtual environments, the physical security at the data center level has to be dealt with. I’m not an expert here, but it really is crucial to have good physical security before you start worrying too much about virtual and cloud security.

  • Cloud security

You need to secure your network and the management software that is being used. Here some basic best practices are:

  • Authenticate all people.
  • Keep it simple (that is, remove the unnecessary components and, in the design phase of your cloud, try to minimize its complexity)
  • Encrypt all data that is exchanged or stored in public locations.
  • Monitor activity to detect threats.
  • Be prepared for anything. For instance, in case of a contaminated system in the cloud, what will be your policy? Will you quarantine or simply destroy the system?

Security demands careful planning and needs to be challenged during each phase of the project.

All in all, it’s very important to remember that all of those topics, from virtualization to security need to be thought of at the beginning of your cloud project. Maybe you will not implement everything at first, but at least you will have a roadmap of what to implement and when. Good anticipation and careful planning are keys to success.

TwitterFacebookGoogle+LinkedInRedditStumbleUpon
Comments: 5
Stephane Wacongne

About Stephane Wacongne

I'm an Infrastructure IT Specialist in France. I have 5 years of experience at IBM in the middleware field. My areas of expertise include service-oriented architectures and cloud computing. For 3 years I've been playing with WebSphere Application Server based products such as WebSphere Portal and over the last year I've been building private clouds for customers in France.
This entry was posted in Private Cloud, Security and tagged , , , , , , , , . Bookmark the permalink.

5 Responses to Eight things worth considering before building your first private cloud (Part 3 of 3)

  1. @houbenator says:

    Good artlcie. I can't find parts 1 and 2. Can you provide links?

  2. @itVARnews says:

    your post is really helpful to the new one on cloud computing era.

  3. I would like to peer extra posts like this .

Comments are closed.