A little over six months ago I started researching the quickly emerging world of “Hyper-converged” infrastructure as a new IT ethos to take my company’s IT operations into the next decade of application and data hosting. I was first introduced to the idea when I attended a webinar from Simplivity, one of the leading companies in this new market. I was immediately intrigued… the underlying question that Hyper-convergence answers is “What happens if you radically simplify the data-center by collapsing storage and compute into one all-encompassing platform?
The broader idea of convergence has been around for a while. I started seeing it with the advent of wider 10 Gbe adoption; the idea of taking a single (or +1 for redundancy) high-speed LAN connection and splitting up into multiple logically separate connections. I.E. you could “converge” management, application, and storage LAN connections down into a single wire. The wider over-arching concept predates even this.
Expand that thought into the virtualization space. Virtualization has been around for a very long time but traditionally if you wanted to get some kind of fault-tolerant system setup it required a complex stack of centralized network attached storage, management software, and a clustered hypervisor. Not to mention (often) separate networking equipment for both the storage and hypervisor nodes.
The promise of hyper-convergence is that many of those disparate parts can go away and instead you can host your workloads on a unified, easily scaled, inherently redundant, platform that encompasses all of your storage and compute needs while simplifying a majority of your networking. Wikipedia sums it up nicely. Rather than reinventing the wheel I will just refer you there if this is a new concept: https://en.wikipedia.org/wiki/Hyper-converged_infrastructure
Hyper-convergence is a rather elegant answer, especially if the product is designed from the outset to BE a hyper-converged platform. My premise in this article is that Scale Computing is one of the few (perhaps the only?) “proven” vendors that have developed a product from the ground up as a hyper-converged system. Based on a lot of the FUD I came across while researching, I got the distinct impression that a large number of people don’t understand this fundamental difference between Scale and the majority of other HCI products currently populating the market. This is a long post, get coffee now… (more…)
Making use of a SAN (storage area network) provides some incredible benefits. I won’t go into depth but at a high-level you often get:
1. Excellent hardware redundancy for data storage, more-so if you are using multiple arrays but even most enterprise single arrays can provide N+1 redundancy. Now we can tolerate power failures, and drive failures, and switch failures, etc…
2. Extra options for historical data integrity/backup/dr – Most enterprise SAN’s support features for volume snapshots and rollbacks. Some even support advanced features specific to protecting MS-SQL and I am sure other database products. Our implementation also provides some great options for DR, like being able to replicate data/volumes from a production SAN over to a different SAN in a different network/datacenter.
3. Administrative ease… managing storage volumes for all of your systems from one interface makes life much easier.
4. Online disk resizing — did your database run out of disk space? You have plenty of space available on your SAN though on which the volume is hosted? No problem, just increase the size of the volume on the SAN (often something you can do while the volume is online and being used) and then increase the partition in windows to take up the new volume space (also an online operation).
For these reasons (and I am sure many many more), SAN’s have become a staple in a lot of enterprise networks. But let me talk about some pain points, particularly in older SAN implementations and particularly around iSCSI and older networks.
I have been fiddling about with setting up a SQL Server 2012 Failover cluster using an Equallogic SAN. After a whole lot of digging about I found two different posts on two different sites which got me about 90% of the way there. However there were some key “gotcha’s” and other information that was missing in both cases and I wanted to document those here in addition to referencing the articles I followed for my setup.
BTW – Just my 2-cents, but setting up clustering is complicated… especially when you throw SQL in the mix. It isn’t bad once you have done it a few times (I tested again, and again, and again in a virtual environment) but there are honestly like 50+ considerations to take into account to ensure everything goes correctly.
I am assuming if you are here you already have a general understanding of failover clustering, know what you are wanting to do and why. This article also doesn’t really cover all aspects of high-availability. I don’t discuss how your SAN(s) should be networked for example. I do touch on a few items though that fall in this area. This isn’t meant to be comprehensive and a lot of it is just for personal reference.
So here are some tips if this is your first go around. These are in NO particular order or grouping (this is very “stream of thought”) so I would suggest reading this from start to finish at least once rather than referencing it as you are going through your setup.
I had a VM using RAW storage format on a ZFS storage object. I needed to delete the RAW hard drive files but couldn’t find them and the “remove” button was greyed out. One post mentioned using “qm rescan” which then allowed the poster to use the remove button but that didn’t work for me. After some research I found out that virtual drives on ZFS storage aren’t actually files but are “ZVOL”s. After a bit more research I came across the solution below to remove these drives manually. (more…)
If you load Proxmox 4.0 from OVH or any of their affiliates you end up with a partition scheme that gives you one big logical volume for data that is formatted to EXT3.
That will work but it isn’t desirable. Starting with Proxmox 3.4, support for the ZFS filesystem was added. ZFS is more than just a file system though and as a result it adds in enhanced functionality. In this article I will be walking through how to transition from the OVH, KimSufi, SoYouStart default partition layout on an existing system running Proxmox to a layout with ZFS. (more…)