|
|
||||
Custom-designed specifically for Java Hosting, our cluster has been implemented using a series of separate DRBD storage layers, a custom high-performance multi-server failover system similar to Heartbeat and Metawerx distributed control software.
This combination increases data locality to each Java JVM, ensures all hardware is performing at maximum efficiency and that each JVM is running on the most suitable server on the cluster. In turn, this provides automatic load distribution to extract the maximum performance of each server.
The cluster has been designed for Tomcat, TomEE, Glassfish and JBoss and also supports command-line JVMs such as standalone ActiveMQ or Node.js instances.
For the developer, our control panels appear as a single seamless server-farm / cloud that can deploy JVMs.
For management, expect increased reliability and performance, decreased stress.
For the technically minded, we have more information below...
We use enterprise-grade Dell PowerEdge servers for our primary Java Cluster. The primary cluster can be easily extended and we can also add more clusters as necessary at our primary data center or elsewhere.
Additional servers are used for the Database Cluster (MySQL/MariaDB/PostGreSQL/MongoDB/CouchDB) and lower-powered high-capacity servers are used for redundant read-only backup archival (onsite + offsite). All systems integrate with Dell's remote-control (DRAC) hardware to allow in-depth hardware monitoring of each server and automated rebooting or manual replacement when necessary.
Any time a Java VM is added, restarted or found to not be running (eg: due to an exit or crash), multiple servers participate in a vote describing their CPU, I/O and RAM load to determine the best server to run the specified JVM based. The vote also considers the individual resource requirements of each JVM.
Based on the vote, the JVM is started on the most appropriate server.
In the case of complete hardware failure of a Java server, all JVMs from that server immediately enter the startup JVM pool and are started on the most appropriate server using the same voting system as above. This ensures even distribution based on the current resources of each cluster member.
Failed servers are automatically rebooted and join the cluster again on successful startup.
For single JVMs, during restart or migration, either a User-Designed Page or our Default Maintenance Page is displayed to users accessing your website/application using Metawerx EpicFailover.
For customers with 2 or more JVMs, the failed node is removed from your private load-balancer and requests are forwarded to all members which are considered "live". When the failed node is ready, it joins the load-balanced cluster and resumes processing. If all nodes are down, either a User-Designed Page or our Default Maintenance Page is displayed to users accessing your website/application using Metawerx EpicFailover.
At any given time, two servers in the cluster are designated as "controllers" and handle the messaging, hardware-monitoring, voting and restart procedures according to Metawerx predefined policies. The controllers continually patrol the entire cluster, reporting any anomalies to Metawerx Support. If both controllers fail or are paused (ie: during a controller failover), individual servers are still capable of restarting their own Java VMs locally without intervention from the controllers. Two servers are designated as "snipers". The snipers are responsible for reacting with the Dell Remote Access Cards directly to reboot failed servers and report any messages present in the DRAC logs.
For the developer at the top-level, our control panels see a single seamless grid-computer / cluster / server-farm / cloud that can deploy JVMs. At this level, the actual hardware that runs the JVM is not important.
All our technology is built upon Open-Source software.
The Java Cluster runs Java Virtual Machines. JVMs are virtualised at the container level for minimal overhead. The physical hardware which runs the JVM is based on the current system load of each underlying cluster member and the resource requirements of the specific JVM.
To isolate individual Java containers we use a combination of AppArmor, Linux Containers (lxc), extfs, iptables and a number of other opensource packages. To control and restrict each container from over-consuming resources, we employ quotas, network rules, CPU usage rules, CPU-affinity and kernel-level priority scheduling for CPU, RAM, networking and I/O.
To provide security isolation, resource allocation limits and control over individual Java containers we use established Linux kernel-level scheduling tools and libraries. Most of our control software is written in Java and a portion is developed in C to intercept Linux system calls for network redirection and monitoring using simple API hooks.
Our storage layer uses either RAID-1, RAID-5 or RAID-10 for all filesystems and databases. Each storage system is replicated using DRBD (Distributed Replicated Block Device) to an entirely separate storage array. Hardware-RAID protects against single drive failure and the secondary DRBD-replicated device protects against enclosure failure or other failure of the storage device (RAM, RAID cards, network cards and server-failure).
When a primary device fails, a secondary device comes online automatically and takes over the requests for the primary device. When the previous primary device comes back online, it becomes the new secondary device.
Storage partitions are presented to the Java Clusters as a single file system, so your software design is not complicated by our underlying redundant hardware layers in any way. Your application sees a single, seamless filesystem.
All writes are persisted, always. We sync all writes to disk synchronously. In the case of a hardware failure, all writes that have occurred will be accessible after your JVM has been moved to a new server.
In case of file deletion or unintended modification, files are immediately deleted on the RAID device and its mirror. To protect against this, we take daily snapshots of each database and file. 14 daily snapshots are kept on our backup system and exposed via a read-only filesystem to your control panel, where you can browse deleted items, restore individual files or folders or even restore a file/folder using a new name.
The Metawerx HA Java Cluster is part of our base system, so there is no additional charge to customers.
In non-clustered environments, a failure of the webserver, OS or database server that is running your Java VM means your application is instantly offline and requires a restore. In the case of some cloud-providers which don't even persist live data, all data is lost unless you paid for "snapshots" in which case you can manually restore your data.
With our clustered environment this is not a problem. Your JVM will begin it's startup within seconds on another available server, ensuring continued availability and uptime.
In addition, since we are virtualising at the Java level, there is no overhead from OS virtualisation per JVM as there is with VPS and VDS platforms.
You can summarise this for your CEO and CFO as follows:
