A question that often comes up is “why should I use config management when I can just use images?” In this article, we’ll explore the differences between images and configuration management, and talk about the benefits and drawbacks of each.
The choices and combinations we have available during datastore selection prove that we’re no longer in the one-size-fits-all datastore world.
Today, there are compelling reasons to mix and match your SQL datastores (such as MySQL, PostgreSQL, Oracle or SQLServer) with your NoSQL datastores (MongoDB, CouchDB, and Neo4J among others). While Oracle may still be the preferred system of record for enterprises, it’s no longer the only game in town.
Developers are starting to use combinations of SQL and NoSQL to solve their problems—sometimes against the wishes of DBAs or IT Departments.
Software Defined Networks in the Havana release of Openstack – Part 2
In the first article in this series, we looked at a simple OpenStack setup with one controller node, one compute node, and one network node. Two tenants had been created with two simple networks. In this article we will turn our attention to the network paths for each of the three VMs that were created. The diagrams in the first article are useful in understanding this discussion.
Discussion hen continues with the first half of the iptables chains that are interjected between the VM and the Open vSwitch process (OVS) on the compute node. In order to keep these articles in bite sized chunks, we will end this s ection after looking at the first two iptables chains, those starting with neutron – which manage the security group rules, the next article continue s through the iptables chains looking at those starting with nova and concludes by reviewing how two different types of packets progress through these chains.
It goes without saying that booting and configuring a server manually every time you need one gets old fast. Thankfully there are a number of tools to help with orchestration and automation available to you.
To list a few you can:
OpenStack is composed of many different projects. The core projects provide compute, storage, and network resources. The Neutron project provides network resources to the OpenStack environment and can be difficult to get started with. To help get the gears turning, I will be discussing some of the functionality Neutron Networking is capable of.
In this blog post, we will walk through using the OpenStack CLI tools to perform common workflows:
We have had a number of customers request the need to be able to create their own Cloud Servers images rather than taking snapshots from our base installs. To fulfill this need, we are announcing a new tool as a preview today called boot.rackspace.com. The tool enables you to utilize the various Linux distributions installers to install directly to the disk of your Cloud Server.
My last holiday took me to Morocco, where me and a couple of friends used motorbikes to travel through the country. To have something to show off back home, we used small cameras mounted on the bikes to film everything. At the end of the trip, our group had filmed about 10 gigabytes of footage and I was put in charge to gather and distribute these files amongst ourselves.
I uploaded all the footage - roughly 55 videos - to a Cloud Files container, b ut obviously I didn’t want to give my portal username and password to my friends. Also, there is no option to generate an index file within Cloud Files, so the only option left to me was to send everyone the 55 video URLs separately. Clearly, a different solution was needed. And so I built one myself.
In this multi-part blog series I intend to dive into the various components of the OpenStack Neutron project and provide working examples of networking configurations for clouds built with Rackspace Private Cloud powered by OpenStack on Ubuntu 12.04 LTS.
In the previous installment, Neutron Networking: VLAN Provider Networks, I provided guidance on configuring networks in Neutron using VLAN tagging. In this fourth installment, I’ll describe how to combine flat or VLAN provider networks with GRE-based tenant networks using the L3 agent and Neutron routers.
If you’re a big PostgreSQL fan like I am, you may have heard of a tool called WAL-E. Originally developed by Heroku, WAL-E is a tool for efficiently sending PostgreSQL’s WAL (Write Ahead Log) to the cloud. In addition to Heroku, WAL-E is now used by many companies with large PostgreSQL deployments, including Instagram.
Let’s unpack what that means. If you’ve ever set up replication with PostgreSQL you’re probably familiar with the WAL. Essentially there are two parts to replication and backup in PostgreSQL, the “base backup” and the WAL. Base backups are a copy of your database files that can be taken while the database is running. You might create base backups every night, for example. The WAL is where PostgreSQL writes each and every transaction, as they happen. When you run normal replication, the leader will send its log file to the followers as it writes it.
Instead of just using a simple socket to communicate, WAL-E sends these base backups and WAL files across the internet with the help of a cloud object store, like Cloudfiles (or any OpenStack Swift deployment). This gives you the advantage that, in addition to just being replication, you have a durable backup of your database for disaster recovery. Further, you have effectively infinite read scalability from the archives, you can keep adding more followers without putting more stress on the leader.
With the help of WAL-E’s primary author, Daniel Farina, we recently added support for OpenStack Swift to it. It’s not yet in a final release, but if you’re interested in checking it out, read on!