In this article I want to share my experience / methodology on the implementation of the Private Cloud. Here I will give the questions we asked during the implementation and how they were solved.

.
We participated in the tender for the development of a Private Cloud service for one large European organization. The purpose of this tender is to offer an infrastructure that provides the client with IaaS and PaaS services. Below are the key points of those. tasks:
- The main operating systems are Windows and Linux on the x86 platform.
- “Standard” list of software for PaaS services (web, database, application server, etc.), including Oracle databases
- preferably also offer Solaris x86
- infrastructure must be located in two data centers (distance <50 km)
- 6 types of virtual machines (from 1 vcpu to 10 vcpu)
- 4 services (SLA): from bronze (best effort) to platinum (RPO: realtime, RTO: 2h)
- firm order for 1000 virtual machines, with a possible increase to several thousand
In Private Cloud, the hardware does not play a key role: servers, storage, etc. can be purchased from anyone, there are plenty of players in the market. All zest is in the program part, which will manage / conduct everything and everyone. With this harder.
')
After a detailed study of those. tasks, we define two directions: studying hardware offers and offers of Private Cloud software. For this purpose, meetings were organized with hardware and software manufacturers.
Iron
We had the following choice:
- Assemble the elements we used to use: HP, EMC and NetApp servers, and the network from Cisco.
- follow the FlexPod architecture
- use VCE Vblock (hardware / software solution)
NB: We did not consider the integrated solutions of IBM or HP, since they were our competitors in the tender.
The first option was crossed out quickly enough, because the client wanted a solution in the form of a block and the most integrated. In addition, it was strategically important to offer the client a solution that does not tie his hands and feet to our organization. Relying on ready-made solutions, we got rid of the problem with the support and development of architecture.
In brief key points of FlexPod and Vblock
FlexPod is a Cloud Infrastructure Design (blueprint) model consisting of Cisco UCS (compute & network) and NetApp (storage). The following image shows the standard architecture of FlexPod FCoE and 10 GbE.

You will have to build and configure the entire infrastructure yourself, but for this there is documentation available on Cisco / NetApp sites, like
this one . The architecture that received the certificate of FlexPod gives the right to a single support service, regardless of the source of the problem: compute, network, storage. True, for one part of our employees, a unified support service is absolutely not an argument.
The flexibility of the FlexPod architecture lies in the fact that you can choose any suitable NetApp storage system, the required number of chassis and Cisco UCS servers. You can add an internal SAN if, for example, you are not satisfied with the FCoE protocol or if SAN & LAN consolidation on a single device (Cisco Nexus 5K) also does not suit you. As virtualization there is a choice from VMware, Hyper-V, Citrix.
Vblock is a finished product, very similar to FlexPod internally: Cisco UCS (compute & network) and EMC (storage), as well as including the VMware hypervisor and controls in addition to the hardware. Unlike the standard FlexPod, the Vblock always uses a separate Cisco MDS SAN switch to access the storage system.

All configuration and assembly implements VCE. There are several series of Vblock: 100, 300 and 700 (from the initial to the most productive).

Each series in turn consists of a number of models. Unlike FlexPod, VCE is the legal entity responsible for Vblock. In this case, the support looks more serious than for the FlexPod. All architecture changes you intend to implement must be validated by the VCE consortium, otherwise the Vblock certificate is lost.
NB: If in the FlexPod hardware, replace NetApp with EMC, then we’ll almost get Vblock. What is Cisco UCS can be read
here .
After meeting with Cisco / NetApp and VCE, we settled on the FlexPod solution for the following reasons:
- FlexPod supports multiple hypervisors, unlike Vblock
- FlexPod has more flexibility in building hardware. For example, if you already have NetApp storage, then adding Cisco UCS and following Cisco / NetApp instructions will give you the FlexPod infrastructure. In the case of Vblock this is not possible, you have to buy the entire "ammunition".
- FlexPod infrastructure changes are not subject to such strict rules as in the case of Vblock. For example, blade servers are always added only in pairs for Vblock.
- In order to provide a high level of service with critical RTO / RPO, we need a solution for synchronous data replication. In the case of NetApp storage systems, we get the MetroCluster embedded solution included in all FAS 3xxx and 6xxx models. For Vblock, this is implemented through RecoverPoint or Vplex, but it costs a lot of money (SRDF / S does not count).
- NetApp is a unified storage system, as well as a back-up system, so there is no need to purchase an additional solution such as EMC Avamar.
Vblock certainly has its own arguments, but in this case, the above elements were more important to us. On this
link, those interested will find a more detailed comparison.
In the second
part , I will tell about the FlexPod design, and then about the software component of Private Cloud.