I manage a fairly large colocated file server for a small business who uses the site as a geographic dump location for video content that gets encoded and delivered to users on the fly through a web interface. The content is all hi-definition material and is unencoded in Transport Stream media format. They keep the content in this format so that they can dynamically serve an array of different encodings depending on the client’s preference. They have a desktop application that their clients can use to connect to the content delivery server and specify what encoding types, aspect ratios, and resolutions that they desire. Anybody who has ever worked with transport stream media knows how large some of these files can get when working with hi-definition content… Some of the files are 100GB in size. The content is typically advertising material for clients and needs to be able to be delivered fast to users across the globe. This is a pretty hefty requirement for a small business, so as a method of management, they decided to get a souped up colocated server located in Europe that will essentially mirror the production content server here in the US. This allows them to have near-real-time availability of content to their three or so clients located in Europe, and with a bonded dual gigabit connection, delivery also occurs in near real time. The idea is really a genius, homebrewed, poor man’s proprietary CDN, and I wish that I could take credit for having thought of the idea. Continue reading »

Here is a subject that does not get enough attention. With RHCS/CMAN, the heartbeat of a node, by default, uses broadcast to let the other nodes know that it is alive and well, and is a member of the cluster. So, in turn, by default we are restricted to using a single network for our heartbeat, and in most cases this is fine… But, what if we want to cluster across multiple networks? Say I have node01 on 10.1.1.0/24 and node02 on 10.1.2.0/24, and I want them to be able to communicate with each other? Well, this is not as trivial a feat as you might assume… In fact, I had to employ some of the finest network technicians (well, not really — but they are pretty smart!) in the south-east to get this to work… Continue reading »

… What the? Ok, so the basic idea here is that we’re going to be creating a cluster, sharing a block device from one server to the other nodes in a cluster as a Global Network Block Device, putting it into an LVM configuration, and formatting the filesystem using Global File System for file locking between nodes… And we’re gonna do this all natively with Red Hat Clustering Suite. This is a good, low-rent implementation of block device sharing in a cluster, where iSCSI or FCP is not available to the hosts. It’s better than NFS because we get real locking mechanisms, and we get our own fencing mechanism for the cluster (which, unfortunately I won’t be covering in this post). I’ve recently had the opportunity to do this as a proof of concept and this is really cool stuff… Continue reading »

© 2013 Dan's Blog Suffusion theme by Sayontan Sinha