For the last few weeks I have been consulting on a private cloud project for a local company. Unsurprisingly this has been based around the typical Openstack setup.

• Nova - KVM
• Neutron - Openvswitch
• Cinder - LVM
• Glance - local files

My architecture is nothing out of the ordinary. A pair of hosts each with 2 networks that look something like this:

All this is configured using Red Hat RDO. I had done all this under both Grizzly and, using RDO, it was 30 minutes to set up.

It’s been a while since I last posted anything, but it is time to. I’ve been playing around a lot with various tools for gathering information about my environment recently. One of the most important tools for storing that information is decent logging. Syslog is proven and solid, but a little creaky. For storing everything it is fine, but getting anything out is not so great.

Logstash is an awesome tool written by Jordan Sissel that is used to “collect logs, parse them, and store them for later use (like, for searching)”. It has an excellent howto, but I have one problem with it: the use of a tar file rather than packages. This easily worked around though, as Elasticsearch have it in their Yum repository.

Ages ago (it seems) I posted a howto on configure NFS using Puppet and Hiera. I have been using this happily for several months and adding a new share was is as simple as adding a line to a YAML file. I was never completely happy with it though, especially after I decided to deploy The Foreman in my lab.

The reason I was never satisfied is because The Foreman makes a really good ENC. I wanted to use this, so I have modified my module to use an ENC rather than Hiera directly.

Yesterday saw probably the biggest FLOSS news in recent times. Certainly the biggest news of 2014 so far :-) By some freak of overloaded RSS readers, I missed the announcement, but I did see this:

Some of us now work for Red Hat, but not RHEL

That is important! This says to me that Red Hat see the value of CentOS as an entity in itself. By not linking the CentOS developers to RHEL in anyway, they are not going to be side-tracking them. Instead, they are simple freeing them up to work more effectively on CentOS.

I had a request on Reddit to share a document I wrote about connect Red Hat Enterprise Linux with Active Directory. The original document I wrote is confidential, but I said I would write it up.

This works for both Server 2008(R2) and 2012. If I recall correctly it will also work with 2003, but may need to minor terminology changes on the Windows side. From the Linux side, it should be fine with RHEL 6 and similar (CentOS and Scientific Linux). It should also apply to Fedora, but your mileage may vary.

{% img right /images/NetappClustering.jpg %}That is a pretty drastic title, especially given that I spend a significant part of my day job working with EMC storage arrays. The other day I replied to a tweet by Scott Lowe :

The boundary between DAS (Direct Attached Storage) and remote storage (be that a SAN or NAS) is blurring. Traditionally a SAN/NAS array is a proprietary box that gives you bits of disk space that is available to whatever server (or servers) that you want. Conversely, DAS is attached either inside the server or to the back of it. Sharing between multiple servers is possible, but not very slick - no switched fabric, no software configuration, cables have to be physically moved.

Okay, I know I am little slow on the uptake here, but I was on holiday at the time. The announcement of Virtual SAN at VMWorld the last week got me thinking a bit.

Very briefly, Virtual SAN takes locally attached storage on you hypervisors. It then turns it into a distributed object storage system which you can use to store your VMDKs. Plenty of other people have gone into a lot more detail. Unlike other systems that did a similar job previously this is not a Virtual Appliance, but runs on the hypervisors themselves.

This is a post which breaks from the normal subjects of Linux and storage.

Today I am going to share a very simple recipe for what I drink when I am cycling. I have some fairly simple requirements for this. 1. It must work (it must rehydrate me effectively) 1. It must not be a rip off 1. I want to have a at least a reasonable idea of what is in it.

{% img right https://www.hastexo.com/system/files/imagecache/sidebar/20120221105324808-f2df3ea3e3aeab8\_250\_0.png %} As I promised on Twitter, this is how I automate a GlusterFS deployment. I'm making a few assumptions here:

• I am using CentOS 6, so should work on RHEL 6 and Scientific Linux 6 too. Others may work, but YMMV.
• As I use XFS, RHEL users will need the Scalable Storage option. Ext4 will work, but XFS is recommended.
• That you have a way of automating your base OS installation. My personal preference is to use Razor.
• You have a system with at least a complete spare disk dedicated to a GlusterFS brick. That is the best way to run GlusterFS anyway.
• You have 2 nodes and want to replicate the data
• You have a simple setup with only a single network, because I am being lazy. As a proof-of concept this is fine. Modifying this for second network is quite easy, just change the IP address in you use.

{% img https://docs.google.com/drawings/d/1XA7GH3a4BL1uszFXrSsZjysi59Iinh-0RmhqdDbt7QQ/pub?w=673&h=315 'simple gluster architecture' %}

Dell has announced the new PowerEdge VRTX (pronounced Vertex). The name comes from a vertex being “the intersection of multiple lines”, alluding to this being a mixture of a rack server, a blade server and a SAN.

It is aimed at branch offices, so it contains 4 servers, storage, networking and (unusually) the ability to add PCI-e cards (up to 8, including 3 FH/FL). These cards can be connected to which ever server you want. These features put in competition with the HP C3000 and the Supermicro OfficeBlade.