Maxta chucks vSAN out of stealth and into El Reg review suite
MxSP promises to be as simple as you are
Exclusive Maxta has officially come out of stealth, and its first stop has been our very own testing lab.
As previously discussed, Maxta Storage Platform (MxSP) is typically spoken of in the same breath as VMware's VSAN, Nutanix or Simplivity. The Register has taken the time to see what makes Maxta think it has the stuff to take on the established players in our exclusive launch review.
For those unfamiliar with the vSAN concept we'll run through a quick primer. vSANs are typically a virtual appliance that grabs all the local storage in a virtual host, connects up with all other vSAN virtual appliances in the same cluster and creates an N+X replicated object store across all nodes. That is to say, you can lose an individual disk – or an entire server – and your data will still be backed up.
This object storage technology is fundamentally not that different from what powers Google's GFS or modern Hadoop clusters. Poke around Nutanix and you'll find people who helped Google design GFS. Poke around Maxta and you'll find Raghu Shastry who worked on the core IO engine for Virsto; bringing an in depth understanding of data tiering to the increasingly "old hat" world of distributed object storage.
The big name players in the vSAN world are Nutanix and Simplivity. These folks sell "converged infrastructure" solutions which consist of a hypervisor, vSAN software, management software and the hardware it lives on. It all comes as a single package; if you want more storage or compute just add more nodes.
The offerings from both companies are excellent. However, the issue with this approach is that the minimum buy-in for both offerings is eye-wateringly expensive. Maxta's approach is to sell the VSAN software, let you handle the hardware, and make their software so automated that no management software is needed.
Making it go
MxSP ships as a windows installer. You'll see a Windows EXE file, a script and a couple of folders. One folder contains a packaged instance of Java and the other contains the real installer; a whole mess of JAR files along with a VMware OVF. Running the EXE triggers the Java-based installer and off you go.
Before you get anywhere interesting in the installer the prerequisites for install are displayed. Each host requires a dedicated network port (for the replication traffic between the MxSP nodes). An IP address on the management network needs to exist for you to be able to access the clustered MxSP Virtual Appliance.
You're going to have to have a vCenter server and have added all your nodes (start with a minimum of three) to a cluster. You also need to make sure that NTP is turned on and actually working on all participating hosts. If you've got that sewn up, it's time to install.
Small tickbox, important decision; error here
You will be asked to enter administrative credentials for your vCenter server, as well as for the local hosts. In addition, you'll be asked whether you want to "enable local copies". This is a critical question; enabling local copies means less space available for your data store, but it also makes life a lot easier if you need to do disk maintenance.
A couple of clicks later and the installer will validate your configuration. Maxta's devotion to simplicity really shines through in this validation concept. For example: the installer asks that you provide dedicated NICs with its own dedicated subnet at the beginning of the install, but neglects to mention that you should allow the installer to configure the network of the hosts.
If you go forth and set up the network beforehand, the installer (which is designed to set that up for you) will error out. It does, however, not get all the way through a lengthy install and then blow up: it kindly checks to see that all is good, informs you of what is wrong and asks you to rerun validation.
Some things it seems to let pass, such as when it complained I only had 4 CPU cores, (minimum 5 required) but proceeded to install happily anyways. It was only after install that I discovered this meant that it would run that system as a "compute node only" system; it would not use that host's local disks towards the MxSP datastore.
Click next a few times, wait for the OVF file to deploy and you're done. At this point MxSP is deployed on your cluster, the disks are mapped and the NFS store is set up inside all available nodes. You are ready to start deploying VMs to that infrastructure immediately.
Sponsored: DevOps and continuous delivery