One of the most valuable capabilities that organizations enjoy with Turbonomic is the ability to create what we call “super clusters”. A super cluster is a virtual resource pool comprised of physical clusters in your environment.
Topics: Case Studies, Infrastructure, Performance, cloud optimization, Efficiency, Super Clusters
There are no shortage of confusion talking about how CPU queueing works and how it ultimately affects your application and environment performance. Virtualization gave the industry something wonderful by enabling sharing of physical hardware resources, but it also opened the door to hidden issues that IT ops and application developers still struggle with every day.
Let’s quickly review what CPU queueing is and how processor wait times can have a catastrophic effect further up the stack.
Now that we have our requirements and constraints defined from our first post, and our working single VM infrastructure-as-code built from our second post, it’s time to start the big build!
We already built out our desired multi-VM architecture that we have a map of from our initial discussions with the dev team. The bonus from this architecture is that we are also leaning into the services-style approach. That means we may be able to break out our SQL and eventual NoSQL clusters as shared services and even port them to a PaaS on the cloud if desired. Everything we do should be done with an eye on the future desired state.
Let’s begin with the simplest layout of what our virtual machine infrastructure needs to look like. We have our public code repository which is showing the real version of what we are building. It’s important because we may save some space in the blog by just focusing on some specific snippets. Please refer to the repository for the full code as you test this out yourself.
In the Monolith to Multi-VM folder under Part 2, we built our single monolithic VM using a VMware vSphere template and Terraform to quickly spin up and tear down a clone from that template. That’s the easy bit.
This is where we turn our attention to Monolith to Multi-VM Part 3 which is the more robust version. For now, we are using a basic template and we will worry about the application deployment in part 4. We just want to take this on in steps that are repeatable and consistent which is the goal of any automation: consistency of outcome that allows you to speed up the velocity of deployment, safely.
You’re very literally getting some bad practices in this code set because we want to show the progression from doing things manually to making the jump to efficient, codified infrastructure-as-code.
What this repository will do that is not the best idea is to literally map out the code for each VM clone as standalone code blocks. Then the part 4 of the series will show you how to DRY (Don’t Repeat Yourself) up that code. What I always dread as a blog reader is when the new methods are so rapidly introduced that it doesn’t give you a chance to see how the machine is made. That’s where I hope you’re finding this progressive blog series style helpful.
Any file you create in the folder with a .tf extension will be evaluated by Terraform as part of the provisioning. You can create these as a large single file, or separate logical files depending on your preference. I prefer to do a separate file for logical groupings of infrastructure. We won’t get into Modules yet…save that for the next blog series!
You will be using a single basic template across all of these clustered nodes which makes it easy. Then we can move the goal post a bit further and add in the app deployments as we close out the series.
Let’s use a single file to describe all three of our application VMs. This file we will reference here is the app-vms.tf file located here in the GitHub repository.
Our new code will include three resources, each coded with the name of the VM to make them unique. The uniqueness is needed or else Terraform will complain of duplicate resources. In our first blog we only used the name “vm” whereas this will use “vm-app-1”, “vm-app-2”, and “vm-app-3” for both the app-vms.tf file and the outputs.tf file.
Example apps-vms.tf:
The outputs generated by the Terraform configuration in our outputs.tf are also explicitly set by the machine names.
Example outputs.tf:
There is repetitive code that we will remove as part of the part 4 of the blog series next. Typing terraform output renders the IPv4 and IPv6 addresses which are picked up by the VMs as they launch.
Next up is the two database clusters which are 3 virtual machines to each cluster.
This file we will reference for our SQL cluster is the sql-3-node.tf file located here in the GitHub repository. We are using the same simple template just to illustrate the cloning process. The next blog will show how to run inline command and remote commands to complete some install scripts for the applications.
That takes care of three app servers and three SQL servers to prepare for the MariaDB cluster. Last step is our future requirement of a NoSQL environment. This is an advantage of doing IaC because we can do a lot of heavy lifting easily in code. Yay!
The final part of our multi-VM deployment is our MongoDB servers. The file we will reference for the NoSQL cluster configuration is the mongo-3-node.tf file located here in the GitHub repository.
The same will go for our actually MongoDB install which will be done with some easy scripts that we have in the next blog.
Just like that we now have 9 servers which can be torn down and redeployed just by typing terraform destroy and then a terraform apply again to clone a new set.
You can also see the final outputs file with all 9 output stanzas together here.
Now you know how to expand your deployment with multiple virtual machines using the Terraform configuration files. What you’ve learned here is that:
The next step is to bring in some simple loops to remove repetitive code and to tighten up our scripts a bit. This won’t change the output at all but will simplify how much code we have. This will prove to be helpful when we go beyond just 3 machines in the cluster. Every step makes your IaC chops more versatile!
Our first post in the series introduced the scenario where our IT teams on the Cloud Rush application had an application needing to make its way to production. This is often the case where the Ops team is handed the working version and asked to work backwards. It’s also important that the reason this happens is that development teams often feel like they have to do a lot on their own to get products built faster. This is our chance to bring those two teams together and use the power of good IT architecture and Infrastructure-as-Code to ensure both speed and consistency of outcome.
There are many questions in the air when it comes to architecting your application for a cloud or virtual environment. Designing with a systems thinking approach means that we want to look at our requirements, constraints, assumptions, and risks. The best way to do this is to look at a specific scenario played out which is what we are going to here in the first of our Couch to Cloud Native (C2CN) series.
We all know the headline that will read “automation is taking away jobs”. What we have to see beyond the headline is that it’s a good thing. It doesn’t take long to realize the benefits you can gain if you take a few moments each day and track the repetitive and relatively mundane tasks we do.
Automation is much more than just the mundane and repetitive stuff. The goal of automation is about increasing the flow (and value) of your work. What makes automation successful are five very key features:
The world of IT Operations has been changing in many ways over the past few years. The rise of public cloud created an urgency for traditional operations teams to adapt their own systems and processes to either embrace a public cloud infrastructure, or to create a more cloud-like experience with their internal infrastructure to keep pace.
Public cloud is on a rocket rise in adoption but will not unseat every data center regardless of the rate of adoption. Many data centers are moving towards managed colocation and on-demand providers, mostly because it opens the door for more programmatic approaches to building and managing infrastructure and removes the overhead of managing environment (e.g. power, cooling).
Infrastructure-as-Code, or IaC, has become one of the most dominant features which allows for the accelerated and more consistent management of on-premises or public cloud infrastructure.
If you’re like me, you probably had, or know someone who had a house with a room that nobody was allowed to go into except for “special occasions”. The furniture was often covered in plastic, and the carpet was impeccably clean, vacuumed weekly despite nobody walking on it except the person using the vacuum.
There is an ongoing discussion (read:argument) around something that is like the Voldemort of technology: vendor lock-in.
Let me start by giving my one line view of the reason for the uprising in awareness of microservices, containers, SDN and the ever-present SDDC (Software-Defined Data Center): This is about agility, not speed.
