At MySQL Connect 2013, I spoke about and demoed High Availability (HA) of MySQL for OpenStack. It was very well received. I’ve heard from many customers who view HA as too complex and do not want to touch it with a 10-foot network cable because there are a number of interrelated concepts and it becomes a pain to implement and test them all. On the other hand, the consequences of not implementing High Availability could be disastrous to a business.
I am very fortunate to visit lots of clients in the UK and Europe that have a huge appetite for running their workloads on OpenStack®. These organizations range from bleeding edge online e-commerce platforms to global enterprises that have mainframes at the heart of their operations. For each of these organizations, there’s the easy fit applications that are perfect fit for a cloud platform – the applications that can be orchestrated and require little maintenance; the applications that handle failure. These include web services, scalable NoSQL stacks like MongoDB and stateless applications that scale behind a load balancer. In many circles these applications are referred to as “cattle”* – larger groups of applications, identifed by the service or its instance ID number, where the first instance is indistinguishable from the numerous other spawned.
Whether you use the Cloud or dedicated servers, you should always make sure you have a plan for your configuration in the event that something goes wrong. This is a series of posts based on a discussion I had with Aaron Scheel, a solutions engineer here at Rackspace.
Whether you use the cloud or dedicated servers, you should always make sure you have a plan for your configuration in the event that something goes wrong. This is the first in a series of posts based on a discussion I had with Aaron Scheel, a solutions engineer here at Rackspace.
1. According to research, a 1-second delay in page load time equals a 16% decrease in customer satisfaction, and a 7% loss in conversions. Meaning a site that usually earns $100,000 a day could lose up to $2.5 million a year.
More and more businesses are shifting from using cloud computing solely for testing and development to extending pieces of their production environments into the cloud. With this shift, IT decision makers are now faced with a whole new set of considerations.
Every time I talk to customer that is joining the Racker family or run’s into an issue with scaling their IT infrastrcuture, I find that they either don’t know how backup and storage needs will effect their business or how to best enable today’s storage product’s to better enable their business needs. It seems that when it comes to architecting the largest most bullet proof solution in the world either the storage portion or the backup solution are thought of last. Don’t get me wrong, I can understand why this is the case and in most case understand why it is the last thing to consider. However I would like to recommend a new way to think about architecting your solution when storage or backup is needed.