I come from old-school IT. I grew up working on my old IBM XT computer, with two floppy disks and no hard drive. I moved up to a 386 with a small HDD, and eventually went to the top of what I thought would be the end of the food chain at the time: The Pentium (I couldn’t fathom anything better. Man, was I wrong!).
It’s amazing how far we’ve gone since those days. Having worked in the world of server virtualization and also private cloud has opened up a new world of IT; a new and much more sophisticated way of architecting solutions and applications. Here, I outline three of the most popular use cases we see today in Rackspace Private Cloud, and also add some color commentary on the application architectures that are typically used when designing your environments.
The three use case I will focus on are:
All of these architectures follow the same logical layout for the OpenStack components, networking components and the compute nodes (physical servers hosting the virtual machines). In all these examples I assume that the environment requires High Availability, so I added in a second OpenStack controller as well as a back up firewall. In each example I then expand on how the application architecture itself will be designed to best make use of the infrastructure below it to leverage it in the most effective manner.
A quick note on how OpenStack logically segregates an environment: To save some time I took some liberty and transcribed from the OpenStack Operations Guide. Here, they are listed hierarchically from largest to smallest:
nova-apiservice, but no
nova-computeservices. Each child cell runs all of the other typical
nova-*services found in a regular installation, except for the
nova-apiservice. Each cell has its own message queue and database service, and also runs
nova-cells— which manages the communication between the API cell and child cells. Did you know that Rackspace lead the development of cells?
For this blog I only focus on availability zones and security groups.
DISCLAIMER: This post is not intended to present best practice, or even the best possible solution for each scenario. The intent was mainly to use simple, high level examples to explain some of the concepts of OpenStack and how they could be applied in certain use cases.
In the diagram, you can see the standard physical layout. Where this becomes more customized is in the way the physical nodes are segregated into availability zones. Segregation allows you to run the right workload on the most effective part of your cloud.
For example, you may not be very worried about the resiliency of the servers housing the development, QA and staging environments; therefore the hardware used on these nodes may use RAID 1 and could also run on cheaper commodity gear. On the flip side, you would want resiliency built into the production environment by using RAID 5 or RAID 10, and possibly also multiple levels of redundancy in the components like memory. Focusing your resources on where it matters most reduces your cost base and gives you the most effective use of your compute power.
Within the virtual machines that then run on your compute nodes you may want to run some developer tools such as a git-server or jenkins to help facilitate rapid application development.
This type of setup is perfect in situations where software development teams want to promote CI/CD (Continuous Integration, Continuous Delivery) and speed up the provisioning of development resources by giving developers the ability to spin up virtual machines, and also to move code through the various stages through to production.
In the example I reference a couple of different Big Data technologies. Rarely would you use only one at a time, as the actual purpose they serve vary greatly. Broken out below are some typical technologies:
For example, you may a need to analyze a huge amount of log files from Apache Web Servers. You could use Hadoop to facilitate this. Using something like Sqoop, you could then pull that data output into a Cassandra database that is great at tracking all the time stamped events, and finally you could use a MySQL backend to store the data in a relational database for billing purposes for your customers.
Below is a similar layout that uses availability zones to segregate the different technology platforms.
Why split up different technologies in availability zones? RDBMS requires high availability like in the example of clustered servers (Multi Master MySQL servers) and may require your physical nodes to run RAID10 for redundancy. These characteristics are not required for technologies like Cassandra, in which fault tolerant Cassandra rings will adjust in the event of errors and deal with single node failures. This means RAID1 would be sufficient, and cheaper commodity hardware would be suitable.
This, once again, shows how to use availability zones to use your environment in the most effective manner.
Here, I focus on a typical three-tier web application. One with a web server, app server and database tier.
This data-driven web application needs to connect to a database backend, which in this case is running on a cluster with MySQL Server. Utilizing security groups the database and app servers can be segregated, allowing only port 3306 (the default port that MySQL Server listens on). Security groups effectively let you limit the traffic that passes between the two tiers. This is obviously a very simplified view of how this works, but it should give you a better picture of how you can use the built in functionality within your private cloud to manage network access.
I hope this gave you some insight into how you can start to use Rackspace Private Cloud in your business. Remember, Rackspace offers tiered support if you need help with designing, deploying and even operating your private cloud; either within your data center, or hosted at Rackspace.
To get started, download Rackspace Private Cloud Software for free. If you’d like additional assistance, you can have open discussions with others in the Private Cloud forums, review Reference Architectures, or check out our Knowledge Center for more information, guidance and technical documentation.