First Hardware Partner is Dell (OmniCube), second is Cisco (OmniStack). These two are certified, but more manufacturer can become a partner in future.
HW (Dell): two mirrored disks (rear, uses a separated Raid-controller) used for ESXi, 2x10Gbit, 2x1Gbit, Accelerator Card (NIC Port for diagnosis)
Accelerator contains transistors that keeps electric current for 3 minutes. In case of power loss, RAM can be written to NVRAM.
2 OmniCubes are enough to get HA
For synchronous OmniCubes a maximum of 1ms latency is highly recommended
Command line tools are available, APIs not
Enabled ESXi shell is a MUST (!)
When rebooting a host set maintenance mode.
Features of SimpliVity
Data Virtualization Platform
Each OmniCube contains an addition hardware board, the Accelerator.
This board does inline (!): dedupe, compress, optimize
Data are kept in this state (deduped, compressed, optimized) during backup, store, eplication across all tiers (RAM, flash, HDD).
On each OmniCube server runs an appliance (OVC) that presents the storage to the host.
Blocks are 8k (fixed) in size.
SimpliVity virtualization is located between x86 architecture and ESXi software
Global Unified Management
GUI is plug-in in vSphere Client (C# Client); plug-in for Web Client will come.
VM centric.
For backups and clones just unique blocks are transferred to the backup site.
Hyperconvergence
SimpliVity is talking about Convergence 3.0, because not just the hypervisor is installed where the data are stored, but also the data is optimized.
This architecture brings storage near to the CPUs.
Needs 43 month of development.
More details
Data Virtualization Platform
Each write IO is going directly to the Accelerator board, so each blocks get checked if it already exists on HDD. If so, it will not be written again.
Think of this architecture when storing data that uses a lot of unique blocks (for example encrypted data).
There is a small write cache on board (just 8 MB (!) relatively small compared to other controller). So it is normally not possibly to swap the board without further steps.
According do SimpliVity there is no performance issue related to the Accelerator board. A problem could arise when HDDs are not fast enough to perform passed writes.
SSDs are just used for read caching and mapping database.
Some meta-data of data-location are stored on SSDs.
A new VM is written on two boxes. Always two (!). The first copy is written onto the Host on which the VM is hosted. For the second copy the system do not guarantee which box is selected at the current release. There is no automatic rebalancing. Think of this when planing a datacenter using more than one location.
10Gbe is recommended but not required (depending on your environment).
Scale-Out: a non-OmniCube (Access host) can be connected to OmniCube storage. But the data-path is going thought a selected OmniCube server. This is because a non-OmniCube host can not read the optimized data structure.
OmniCube is available in different sizes. They can not be mixed within an (VMware-)datacenter.
There is just one public cloud provider at the moment that is supported to backup to: Amazon.
More datastores can be created. Reasons for this can be the backup policy (see there) or because of kind of quotas for VMs. There is no reason for performance. Datastores can be changed in size (increase, decrease).
There is a maximum of 16 OmniCube-datastores
Backup
Snapshot are per VM, not per LUN/store.
At the moment there is no file level restore, this will come in next version.
Backup is policy based, a policy is defined by (up to 16) rules. A policy is linked to a datastore. This is the default for all VMs created on this datastore after the policy was selected. A new assigned policy on a datastore applies to VM created afterwards. Because of backup policies it makes sense to create more than one datastore. Backup policies can also be applied to a specific VM, this overrules the policy set on datastore level.
Because data blocks already exist, a backup job writes very less data.
Because data blocks already exist, a restore job is finished within seconds.
A restore can just be done to the OmniCube store(!)
Minimum frequency: 5 minutes.
Backup/restore is build in vSphere plug-in.
Federation Overview
Components:
vCenter Server. It is not allowed to run the vCenter on one of the OmniCubes (!) within the managed federation.
SimpliVity Arbiter runs on vCenter Server. You can think of it like a quorum. Therefore vCenter must be installed on Windows.
SimpliVity vCenter plug-in.
VMware OVF Tools (to deploy OVCs)
Options for Federations (all OmniCubes within a configuration):
0+ – Just one node
1, 2+0, 2+1
4+4
4+4+4
…
at the moment max. 12 OmniCubes per Federation
at the moment max. 6 datacenters
at the moment max. 4 OmniCubes per datacenter
Additional Notes
Per OmniCube you can run 50 VMs as a maximum
Information for backup policies are shared within a federation.
Dedupe database is per OmniCube.
A OmniCube can be removed from federation by GUI.
Hardware
3 Models at the moment for Dell servers, 2 for Cisco servers.
Expansion option for 2 additional NICs. Ask SimpliVity for certified hardware.
Per default, 10Gbit ports are used for storage-traffic only, 1Gbit ports are used for VM traffic, management, vMotion. This can be reconfigured after installation.
When using just 10Gbit, MTU size must be configured (changed to 9000).
Just 2 nodes can be connected directly, without a switch.
HDD are configured as Raid6 respectively Raid60 (CN-5000).
SSD are configured as Raid1 (CN-2200)respectively Raid5 (others).
You can not mix different OmniCubes models within a datacenter.
Patch Management
Information about patches are provided by SimpliVity.
It is not recommended to use Update Manager without checking SimpliVity homepage. At the moment there is no automation.
If you need a special patch that is not listed for installation, request the path from SimpliVity Support.
Monitoring
No SNMP directly from OmniCube.
For monitoring it is possible to use vCenter methods.
OmniCube is logging in ESXi log files (use syslog server).
You can not use VMware alerts to monitor storage because ESXi hosts just see logical space allocation.
Arbiter service should be monitored!
Backup
SimpliVity backups are full, independent (is not related to a parent).
Using the VMware snapshot workflow; can use application consistence (VSS). You have to take into account the time, the VM hosts need to create an squeezed snapshot to adjust the frequency.
Non-application consistent backups are finished in seconds.
Manual backups are not retained (!).
Backups are not removed when deleting a VM. Therefore when deleting a VM from datastore, no additional datastore space will be available. To get more space you have to delete backups too.
Even backups created by policy can be locked to not get deleted by retention.
You can copy backups by using GUI.
For backup policies you have to provide:
How often to backup
Where to store
How long to retain
Old backups will be delete by retention even new backups fail.
You can apply an empty (no rules) policy to a datastore. You can do this for example for test datastores.
Take care to look at retention days. The system counts for a day a backup is made. Tip: add column “Max. Backup” in GUI.
You can’t see nor control on which OmniCubes backup blocks are located.
VMware View & SimpliVity
At the moment linked Clones are not supported! You should not use it.
You can use Pools without Composer. The cloning process will be very fast, but managing these pools are not that comfortable as linked clone pools.
ESXi Access Node
Technology to connect a non-OmniCube to OmniCube storage.
The new host can run VMs on OmniCure datastores.
There is a 1:1 connection between a non-OmniCube and a OmniCube server. In case of a OmniCube host-failure, the access node can still access data because IP configure is migrated to another OmniCube host.
The additional host does not increase the maximum active VM count per datacenter (50 VMs per OmniCube).
There are advanced parameters to configure for ESXi 5.0/5.1/5.5; a reboot is required.
(Metro)cluster
To eliminate a split-brain situation, vCenter (incl. Arbiter) must be located on a third location.
vCenter can also be connected using slow links. Arbiter is just used for tie-breaking
In case (of 2 OmniCubes) link between OmniCube and vCenter is loss, both OmniCubes stop working.
Networks
3 networks are necessary: Management, Federation, Storage.
For deployment process it is recommended to use standard vSwitches. Afterwards this can be changed.
For deployment process it is recommended to leave NICs at active/standby. Afterwards this can be changed.
For direct connected OmniCubes active/standby is a must.
Deployment
It is recommended to draw a diagram of planned deployment. Send this information to SimpliVity support, so SimpliVity can reserve support resources.
Fill in Pre-Flight List BEFORE installation.
3 NTP server are recommended.
The first deployed OmniCube creates the federation. Therefore it is important to wait to first OmniCube to complete. Further OmniCubes can be deployed in parallel. If the second OmniCube starts to deploy before the first is finished, two federations will be created.
A vCenter user with specific permissions must be created manually.
At the moment, ESXi is just pre-installed. A few additional settings (NTP, …) are set. Other like vSwitches are note pre-configured. This steps has to be done manually (or scripted). OVC VM should be already deployed on OmniCube server (do not start or modify it). If it is already deployed, installation can be done over WAN. A OVC template is also deployed by default in local datastore.
To check version of OVC, browse local datastore for version.txt
In an n+1 configuration, every node has to be configured to host all network port groups. Even if network links are down. This is necessary because deployment wizard checks these settings. In production federation traffic will be routed through management port if federation port is down.
Steps:
Install vCenter plug-in
Install Arbiter
Put the boxes into the rack
Configure IPMI
Configure ESXi
Default password for user root: simplicity
Add second NIC to switch0
Configure IP settings
Enabled ESXi shell is a MUST (!)
Add Host to vCenter
Network vSwitches
Configure MTU
Set active/standby
Deploy SimpliVity
Configured customer name during the setup will just be used for support bundle.
If deployment fails, delete OVC and start deployment again. OVC will be deployed using template and OVF tools.
Support
Because SimpliVity is a start-up company, support is very flexible.
Support Level (in both level: 7×24 of phone call, email and remote access):
Gold: 4-hour parts delivery (from time of diagnosis); depends on location.
Silver: Next Business Day parts delivery (from time of diagnosis).
Support capture can be created by GUI. Transferred information about customer is just its name.
Phone-Home can be configured using GUI. Up to 5 additional eMail addresses can be configured.
Failure situations
OVC tries every network link to communicate and fails over if necessary.
If link fails between OmniCubes Arbiter decides which node to stop. VMware HA takes action!
If OCV fails, traffic is redirected to other OmniCube.
If local storage fails (more the 2 HDDs, 2 SSDs), traffic is redirected to other OmniCube.
Access host is redirected to other OmniCube and continues to work.
Accelerator contains transistors that keeps electric current for 3 minutes. In case of power loss, RAM can be written to NVRAM.
Capacitor not transistor…