When it comes to cloud architecture, the world is full of opportunity as well as potential pitfalls. In this blog series, we will take a look at high-level cloud architecture considerations and some of the common mistakes people make when deploying Eucalyptus clouds.
Note: This series is a result of the collaborative efforts of all members of the Eucalyptus Professional Services team. A special shout-out goes to Ernest de Leon and Tom Ellis for their contributions and review time. This content is considered part of our Open PS initiative, so comments, questions, and improvements are welcome!
Cloud Solution Architecture
Solution Architecture is the foundation upon which many new deployments are launched in data centers. The most important component of a Solution Architecture (henceforth notated as SA) is integration with existing IT systems and platforms. This takes a multi-pronged approach, but some of the most common integration points (and consequently pain points) are: networking, applications, storage, monitoring, power, HVAC capacity, etc. The philosophy for designing a Eucalyptus Private Cloud and integrating this cloud in an existing customer's data center is defined at a high level in our previously published repeatable process and reference architecture information. This blog, and possibly other to follow, are an attempt to take it down to a tangible, practical level needed for detailed deployment planning.
Today, the most rigid component of any data center infrastructure is networking. This is due to several factors, some of which are: a mix of legacy and new equipment, improper initial design for scale, the use of vendor proprietary technologies and/or protocols and even poorly designed applications which have hard coded network information. Needless to say, this ongoing headache for datacenter managers will inevitably creep its way into the Eucalyptus design.
The existing datacenter network is also incredibly important to the Eucalyptus infrastructure, as it will determine what networking modes you can deploy. As a result, networking becomes one of the most important components in the design of a Eucalyptus Solution Architecture. At a high leve, the things to watch out and gather requirements for are:
- What are the constraints (everyone has them)
- Legacy equipment, old switches, not configurable enough.
- Make sure you're talking to the networking guys - they'll know and love you if you can fix it.
- Control over infrastructure (physical layout, etc.)
- VLANs in use right now (what's out of bounds)
- Integration points are different b/t DNSMasq (Euca uses) and Bind (which customers use..)
- Colo building out a datacenter as you go? They control the VLANs, flexibility there? Do servers have to cross the core, or will they be on the same backplane? Probe this kind of thing.
- Probe heavy media and network intensive applications
- If not concerned about security groups, etc. might have bandwidth concerns
- If so, MANAGED(-NOVLAN) network modes might not be optimal (SYSTEM preferable)
- Don't want to be dependent on functional CC for instance access
- Communication w/back-end services (back-end connectivity)
- Oracle RAC, mySQL Cluster, other DB Clusters, probably not virtualized
- Have to make sure to count this in network I/O load in design - aggregate networking
- If using persistent storage (SC w/SAN adapter, or even w/o) - third private network, storage only b/t NCs and SAN to avoid traffic conflicting with SAN. Most won't need, but some will.
- Misc. -- Ask deep questions...
In the next post in this series, we will take a look at the application stack intended to run in the cloud and how it can affect cloud design decisions.