The setup was performed on a freshly installed CentOS 6 VM using a “minimal ISO” image from the CentOS Project website. The VM was set up on a local VirtualBox installation, all settings being left to default except for the memory which was increased from 512Mb to 1Gb. Of course, the more, the better, but 1Gb is the lowest one can go without facing serious memory swapping.
Initial Setup
The successful Centos 6 installation leaves the external network interface disabled upon the initial boot, so this must be fixed before anything else. One must look into /etc/sysconfig/network-scripts/ifcfg-eth0 and change the ONBOOT parameter from no to yes. Afterwards, the network subsystem must be restarted, e.g.:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0 ... ONBOOT=yes ... # service network restart
Once the VM gets Internet access, it’s a good practice to update everything and reboot it before going forward with the Chef Server installation:
# yum -y update # reboot
There is one important change one must perform in order to get the Chef Server properly set up: the hostname, as localhost.localdomain won’t do. The hostname must also be associated to a static IP address, which can be achieved in VirtualBox by playing with some networking settings (not presented here).
Inside the VM, this is easy to put in place:
In this text I intend to discuss some practical aspects related to the “multiple 9” percentages that are advertised by vendors regarding their reliability. Oh, and how to achieve 100% uptime (NOT).
Definitions
SLA stands for Service Level Agreement and it is a binding contract between the vendor and the customer. It is usually expressed as the percentage of the time reference window (e.g. a year) when the Service should be functioning normally, delivering its desired output.
The Uptime of the Service represents the numeric portion of the agreement above, expressed either as a percentage or by using time units.
Note: the uptime/downtime definitions above do not completely apply with Services provided through different infrastructure sets, e.g. to different geographical regions, from different data centers. A downtime in one geographical region does not mean that the Service is unavailable to just every customer out there so a different calculation method must be figured out. A solution may be to estimate the number of requests not served during the downtime by looking historical data up and then do the Service availability estimates from that particular numeric figure.
How many 9s?
AWS provides a complete monitoring engine called CloudWatch. This works with metrics, including custom, user-provided metrics and it’s able to raise alarms when any such metric crosses a certain threshold. This is the only tool used for perfomance monitoring tasks within AWS.
This text will cover a monitoring scenario regarding deploying an arbitrary application to the “Cloud” and then being able to determine what causes performance limiting, be it in the application code itself or coming from limits enforced by Amazon.
Scenario
Let’s assume that you have just started using Amazon Web Services and are deploying applications on this free tier or by using general purpose (T2) instances. You quickly learn that the general purpose instances work with “credits” that allow dealing with short load spikes through performance bursting, but when these credits are exhausted, instance performance is reverted to some baseline. These particular details do not make a lot of sense, but you need to know if the application can meet the desired service targets while sticking to this setup.