How is the Cloudistics platform managed?
• How is the Ignite Cloud Controller management service secured?
• Which guest operating systems are currently supported?
• Does Cloudistics support 32-bit operating systems?
• What type of functionality does the guest agent provide to the VM instance?
• Are APIs available? If so, where are they located?
• Can the Platform run Ansible, Puppet and Chef?
• What browsers are supported for the management portal?
• How do you migrate workloads to the Cloudistics Platform?
• What is a Category?
• What is a Tag?
• What is a Migration Zone?
• What are Storage Blocks and Storage Pools?
• What is the relationship between compute nodes and migration zones?
• What is the relationship between VDCs, Migration Zones and Storage Pools?
• Is the system capable of Self-Service and Role Based Access Control (RBAC)? If so, what type of Self-Service and RBAC controls are available?
• What is the application marketplace?
• What is the difference between the public marketplace and the local one?
• Can I add a live application to the local marketplace?
• What are templates?
• How are templates stored and where?
• How much space do they take?
• When I create an instance from a template, does it copy it first?
• What happens when I create many instances from the same template?
• How are applications added to the global marketplace?
• What are Software Defined Networks?
• What is network virtualization?
• Adaptive Overlay Networking
• What does the Cloudistics networking layer offer?
• How does Cloudistics attach to an existing network?
• Can I use my existing firewalls?
• Does Cloudistics support distributed firewalls?
• What is Micro-segmentation and how is it different than perimeter firewalls?
• What are Application Security Profiles?
• How do you offer multi-tenancy without physical clusters or expensive VMware licenses that let you carve physical resources into virtual datacenters?
• How can I prove that your Micro-segmentation is actually segmenting the network traffic?
• What is the operating system used for the SDN functionality?
• What features and functions do Open vSwitch and OpenFlow provide?
• What are the networking protocols to be used?
• What is BGP?
• What is VRRP?
• Can two VNets have the same subnet?
• How does AON compare to NSX?
• How does AON compare to ACI?
• What type of firewalls can be created and at what level are these firewalls?
• What does the source and destination represent within the firewall rules?
• What is the underlying hypervisor?
• How are the compute nodes connected to the Top of Rack Switch (TOR)?
• Can a customer have diverse types of compute nodes in the same compute block? Does each compute block have to be the same configuration?
• What percentage utilization is achievable on the compute node?
• What type of storage services are supported?
• Does Cloudistics offer object storage?
• Where does your Cloudistics Block Services software run?
• Where does your Cloudistics File Services software run?
• Is the storage active/active or active/passive?
• Do you support Dedupe/Compression and is it global?
• What is single instancing and how does it compare to dedupe?
• What level of data encryption is included in the platform?
• What type of RAID protection do we implement?
• Does Cloudistics support erasure coding and if so how?
• How is storage connected to each VM?
• How are the storage blocks connected to the Interconnect?
• What are limitations to the storage blocks in terms of scale?
• If a VM has multiple SCSI drives attached to it for performance reasons on the current infrastructure, how does Cloudistics migrate the VM?
• How does a migrated VM connect to legacy storage?
• Can I archive data directly to the cloud?
• How does Cloudistics leverage its copy data technology and cloning to reduce the R-factor for Hadoop workloads?
• Does your storage incur any overhead on the compute block and how does this differ from Nutanix?
Is backup is built into the platform?
• What is your backup RTO and RPO?
• How do I restore from a recovery point?
• How do I restore a file from a backup?
• Do you support retention policies, if so for how long?
• Are the backups compressed and deduped?
• Is the backup encrypted?
• How does the Cloudistics disaster recovery work?
• Can I DR to a public cloud?
• What is the difference between the Spark and Spark Guardian edition?
• Does your portal support Two-Factor Authentication (2FA)?
• What is your security policy for Pen Testing and Hardening?
• How do you integrate with Containers?
• What type of support is available?
• What is our SLA and how does it work?
• How does the real-time chat work?
• How does support mode work?
• Who provides support for the platform (hardware and software)?
Who is Cloudistics?
“Cloudistics was founded on the idea of bringing the benefits of the public cloud and the ease of use and simplicity behind the firewall…”
We introduced the first Composable Cloud based on our experience and disappointment with an all public cloud strategy. It’s the same journey thousands of customers can relate to: the need to be more agile, to scale and grow based on business needs, while maintaining data sovereignty and predictable cost controls.
Why choose Cloudistics?
Cloudistics enables you to master cloud competency, complexity, compliance, and unanticipated costs by altering the cloud experience. Our unique approach led us to create a composable cloud that is “customer inspired”, software defined and specifically designed to provide the desired and expected benefits of a public cloud model with the control and security of a private cloud model, without compromise or sacrifice.
What are the key benefits and differentiators of the Cloudistics Ignite Cloud Platform?
- All-inclusive software-defined private cloud platform
- Easy to implement, deploy, operate, maintain and support.
- Manage all resources from a single web console
- Deploy NEW apps and services in minutes
- Limitless independent scale of network, storage and compute resources
- Proactive, seamless patch and update—without reboots
- Single contact support
- Designed for IT Generalist administration, no special cloud competency required
- Integrated back-up, disaster recovery, high availability and security
What are the primary use cases for Cloudistics Ignite?
- Advanced Virtualization
- Cloud IaaS
- Big Data and Analytics
- Continuity as a Service
- Remote and Branch Offices
Which applications can run on Cloudistics Ignite?
Cloudistics web services API makes it possible to run practically any application on the platform. The API service makes it possible to develop your own automation software or other useful tooling. It is the same API service used for the creation of the application controllers that automate operations. An example of this is our built-in orchestrator for deploying Splunk, which is an application that consists of multiple VM types, all of which must be deployed together.
Where can I find a Cloudistics Ignite roadmap?
Our roadmap is not publicly available, but we are happy to discuss your needs and respond accordingly under NDA.
How is Cloudistics Ignite sold?
Cloudistics is sold either direct, through an OEM partner or a CSP/MSP. It is sold as a complete platform and includes all pre-validated application templates in the marketplace, the web-based Ignite Cloud Controller, networking, storage and compute blocks. The platform includes an API for the creation and refactoring of applications so they can be made cloud native, you can also use your own licensed products.
Is the software available for a DIY implementation?
The platform is not available as a DIY. This eliminates the risks associated with disparate, unvalidated software and hardware. It also enables Cloudistics to deliver a consistent premium experience for Administrators, DevOps, Tenants and End-Users. This consistent premium experience also enables a CSP/MSP to provide a reliable, repeatable, cost-effective service and support experience to their customers.
How is Cloudistics implemented and deployed?
Cloudistics will collect site survey information and then ship the platform onsite and ready for a certified technician to perform a white glove deployment. The physical delivery, implementation and deployment takes less than a day and the actual system setup takes less than an hour. The necessary data center connectivity information needs to be collected prior to installation to avoid any delays in deployment.
How does the platform connect to my existing environment?
Cloudistics connects to any existing environment with a network connection to your top of rack switch or connectivity core and a range of IP addresses. From a network perspective, we are just a node on the network. The platform handles all east/west bound traffic within the platform, and the north/south bound traffic is passed through the network spine.
How is Cloudistics Ignite operationalized?
Application resource orchestration, optimization, performance and hardware management is automated, so the platform can be administrated by an IT generalist. The complex management operations common to many other virtualization and cloud architectures are not necessary.
How is Cloudistics Ignite maintained and supported?
Patches and updates are automatically pushed to the platform without the necessity of a reboot. This enables you to always be in support compliance.
How are maintenance upgrades for disconnected scenarios achieved?
Support is provided by onsite delivery and implementation by a certified technician via a flash drive.
What does Cloudistics mean by “Composable Cloud”?
- The platform is composable beyond the hardware elements
- Dynamic assembly of application resources as needed
- Returns resources to a global free pool when the workload terminates
- Physical and virtual network resources are both composable and can span multiple sites
- Unified view of utilization and consumption by the virtual data center (VDC) and applications
- Intelligent application and service placement of both VMs and vDisks which optimizes performance
Cloudistics Ignite Cloud Platform is a composable, software defined, private cloud platform managed from the web that operates and scales free of typical hardware-specific dependencies and is programmatically extensible. All hardware elements are abstracted by the software defined private cloud platform. Network, storage, and compute abstraction delivers compelling simplicity, efficiency and performance advantages beyond bare metal implementations.
The Cloudistics platform can support the following capabilities:
The Cloudistics platform separates the management services from on-premise infrastructure to deliver increased business agility coupled with greater flexibility and speed of service provisioning. The management services are driven by the Ignite Cloud Controller which is a secure SaaS portal. It automates hardware management and controls application deployments, orchestration, performance optimization and all management down to the hardware. The Cloudistics platform uses a hosted, web-based management portal that moves management compute and storage overhead away from your cloud infrastructure, boosting your performance. A hosted management interface also facilitates anywhere, anytime access and simplifies multi-site command and control.
How is the Ignite Cloud Controller Management Service secured?
The cloud controller uses industry standard secure and encrypted communication between the Ignite Cloud Controller management and the infrastructure (storage, compute and network). This secure method provides confidentiality, integrity, and authentication through encrypted channels. Control plane encryption protects against man in the middle and other attacks that could compromise network security. All customer data resides on-premises; only metadata resides in the controller.
Unlike other management systems, security is maximized by leveraging an ‘inbound-only’ approach. There is no requirement to open any inbound firewall ports, only outbound ports. All communication is initiated from the data center to the web portal using SSL and TLS encryption, and upon authentication, the portal communicates back to the cloud platform.
We support an extensive list of operating systems with our agent. The supported operating systems that have a Cloudistics guest agent include all major 64 bit flavors of Windows including all server operating systems. Supported operating systems include Windows 2008 R2, Windows 2012, Windows 2012 R2, Windows 2016, Windows 7, Windows 8, Windows 8.1, Windows 10 and all flavors of Linux.
In addition to the aforementioned operating systems, Cloudistics also has agentless technology that supports a wide selection of operating systems including Solaris and all BSD flavors. In addition, older flavors of Windows such as Windows XP are supported in agentless mode.
We provide a guest agent for each VM. Virtio drivers (i.e., para-virtualization drivers) are needed for communicating with our guest agent. The guest agent tracks CPU and memory usage and is used to quiesce the VM prior to a snapshot the ensure application-consistent snapshots. With Cloudistics agentless technology, most operating systems that work on Intel processors will work on the Ignite platform.
There is scripting capability in the guest agent; a pre- and post-hook allows advanced users to “prepare” an application before a snapshot is taken.
Guest VMs can run in:
1. Enhanced mode, with para-virtualization drivers, and using our embedded agent
2. Enhanced mode with para-virtualization drivers but has no agent
3. Compatibility mode, with no para-virtualization drivers, and no agent.
Yes, with the Cloudistics agentless technology. In the case of Windows OS’s, para-virtualized drivers exist to help improve the performance of agentless guests.
The agent is used to provide application consistent snapshots, application statistics and performance acceleration for storage and networking. Note that some operating systems e.g. (*BSD) that don’t have Cloudistics guest agent support already have built-in para-virtualized drivers that provide storage and network performance acceleration.
Cloudistics Ignite Cloud Platform is programmatically extensible and was developed with application controllers that can automate operations, the controllers are built using the Cloudistics web services API.
Customers and 3rd parties may also develop their own automation software or other useful tooling using our API. Cloudistics web services provides API access to the Cloudistics to virtual datacenter and is used to create resizable resources, manage workloads and retrieve information about the underlying infrastructure.
CWS will continue to grow as new capabilities are added to the platform. API reference and documentation can be found at https://github.com/Cloudistics/REST-API. DevOps can use these API’s to orchestrate applications, gather statistics and usage for billing and SLA’s measurements.
Yes, the platform can run Ansible, Puppet and Chef. Simply download an appropriate template and run the instance and begin configuring the service for use.
Cloudistics supports the Google Chrome browser. Download the browser here: https://www.google.com/chrome/browser/desktop/index.html
Existing VMware and Hyper-V VMs are easily migrated to our platform through the template import function within the portal. Cloudistics will automatically migrate existing VMDK’s and VHD’s to a Cloudistics template that can immediately be launched upon completion. If the existing VMs cannot be migrated and you are looking for more storage, we can provide an NFS/CIFS/iSCSI mount to that VM.
The most important abstractions necessary to understand the Cloudistics architecture are categories, tags, migration zones, storage pools, and virtual data centers (VDCs).
Categories are used to categorize or classify computer nodes, for application placement, and for managing oversubscription as described in more detail below. A node can have only one category assigned to it.
Categories are used to classify the following;
- Compute nodes
- Application placement
- Managing oversubscriptions.
The structure can be formal or informal such as;
- Use case
- Business unit
The only restriction is that a compute node may have only one category assigned to it.
Tags determine where an application can run, they are used to support VM placement and migration. Each node can have many tags assigned to it. When a new application is created, it can specify tags, or it can run on any node without limitation. Cloudistics uses tags to ensure migration viability and will not fail due to unsupported instruction sets. Together, categories and tags form compute constraints so applications only run on a node with those constraints. For example; the application can also specify that it needs to run in a node belonging to a certain category, and we will also enforce that during application migration. For example, if we categorize based on BU, then an app running on a node belonging to HR can only migrate to other nodes belonging to HR.
Migration Zones are a set of compute nodes where a VM may migrate. Compute nodes from different categories may be part of the same migration zone. There is no limit to the number of nodes in a migration zone or the supported number of nodes. Nodes with dissimilar instruction sets and architecture features may be part of the same migration zone. Unlike a cluster, when a node is added to a migration zone, no other node needs to be aware.
A Storage Block is a pair of storage controllers and all storage accessed through them. A storage block is entirely at one site.
The storage block hosts all-flash storage and several other value-added services including but not limited to snapshots, replication, disaster recovery, single-instance storage. Just like the compute block, the storage block is 2U, contains two storage controllers and each block can scale up to 192TB. Multiple storage blocks can be federated to form large storage pools. VMs are directly provisioned storage blocks.
A storage pool is a federation of one or more storage blocks creating a global pool of storage capacity. A storage block is the basic unit of storage that consists of dual controllers and a set of flash drives. A new storage block can be added to an existing pool to increase its capacity or a new pool can be created from the new storage block. Like a migration zone, it can span multiple sites. For reasons of performance, multi-site storage pools should be connected with high-speed interconnects.
A migration zone (MZ) consists of one or more nodes and permissions to access one or more storage pools. Any VM that starts within a MZ will only migrate between the nodes that comprise the MZ and can only use storage that is permitted for the migration zone.
This capability is used to provide physical separation between multiple tenants running on the same infrastructure, particularly when compliance requirements dictate physical separation such as PCI environments or financial domains.
Environments that don’t have physical separation requirements may use a single migration zone for an entire physical site. There is no limit on the number of nodes in a migration zone, and nodes can be added or removed from a migration zone without any impact on running applications.
A virtual data center (VDC) contains storage, compute and memory resources from one or more migration zones and storage pools, a VDC may have resources across multiple physical sites, enabling a single global view of geographically disparate resources. Most importantly, resources in a virtual data center are virtualized into a pool and are not directly tied to the underlying hardware providing those resources. The VDC contains processor cores, memory and storage capacity, and a list of hypervisor nodes. When VMs are started within a VDC, Cloudistics Ignite automatically determines the correct compute nodes to run applications on based on the underlying physical resources (within the MZs that constitute the VDC) and the demands of the application.
The physical cores, RAM and storage pool GBs are sliced into smaller virtual units – vCPUs or multi-threaded cores for compute, 1 GB for RAM and 1 GB for SSD Flash storage. A VDC consists of a certain number of vCPU units, a certain number of 1 GB RAM units and certain number of 1GB storage units, and these may come from one or more migration zones and storage pools. VDCs can span sites, like MZs. While migration zones gave us physical separation, VDCs give us logical separation.
Is the system capable of Self-Service and Role Based Access Control (RBAC)? If so, what type of Self-Service and RBAC controls are available?
Cloudistics Ignite supports multi-tenancy, including network micro-segmentation and RBAC
The Cloudistics Application Marketplace allows you to instantly deploy and scale, virtual machines, operating systems, and applications, in a matter of minutes. The marketplace hosts pre-validated applications that are already tuned for Cloudistics. Using an application from the application marketplace is as simple as downloading it and running it. The marketplace supports multi-tenancy and provisioning on demand for your convenience. An administrator does have the option to limit access to specific applications based on roles and user profiles
Cloudistics maintains the public marketplace, where pre-validated tuned applications can be downloaded by anyone. Ignite also allows customers to install applications directly from ISO files. Typically, applications installed from ISO are then configured and a “golden master” or template is created from them. Customers can publish these templates to their local marketplace, also known as a template store. Applications published to the local marketplace are very similar to the public marketplace, with the important caveat being that such applications are private to each customer. Just like the public marketplace, applications published to the local marketplace can be used seamlessly across any number of physical sites that a customer infrastructure may have.A virtual machine image can also be imported to a template and accessed by authorized users.
Yes. To add an application to the local marketplace, go to the application and select create template. This operation creates a new template and adds it to the local marketplace.
A template is a “golden master” image of an application. You can create a template from any application by selecting the create template action. Templates themselves are non-modifiable and this property enables revision control. When an application is instantiated from a template, the instantiated application can read/write data as it desires without changing the template.
Templates are stored in the template store. The template store, also known as the local marketplace provides global namespace across all physical sites. From a logical perspective, templates appear to be truly global, in that all physical sites of a customer see the same global template store and can use it identically. Internally, templates are stored in each storage block and replicated on demand across sites.
That depends on the size of the application. Templates are sparse (thin provisioned) and only take up as much space as the actual data stored within them.
When the first instance of an application is created from a template, a copy is made from the template store and laid out directly “as a disk” on a flash pool.
When more than one instance is created from the same template, only the first instance results in a data copy. All subsequent instances are clones and require no additional copies.
Cloudistics continually adds applications to the global marketplace. They are validated and optimized for the platform. If you have a request for additions to the marketplace, please send a message to support from the real-time chat window.
SDN or Software Defined Networks allows centralized control of all network switches in a data center using an API. SDN separates the control plane (the software that decides how and when to route traffic) from the forwarding plane (the part of a network switch which forwards data between input and output ports). The control plane is implemented as a separate SDN Controller which can be used to centrally configure all the networking switches.
Applications use a northbound API to program the SDN controller, which, in turn, uses a southbound API to manipulate the forwarding planes as desired by the applications.
Network virtualization is a software used to create one or more virtual networks on top of a physical network. It is analogous to compute virtualization, which allows the creation of one or more virtual machines on top of a physical server.
Just as a virtual machine supports all the attributes of a physical server such as CPU, RAM, Disk, NICs, etc., a virtual network supports all the Layer 2 to Layer 7 networking services available in a physical network such as switching, routing, firewalling, QoS (Quality of Service), load balancing, and so on.
Just as workloads should not have to share VMs, they should not have to share virtual networks. And just as there is strong isolation between VMs, there needs to be strong isolation between the virtual networks.
AON is the name used to describe Cloudistics’ approach to network virtualization. Our patent-pending technology does not use the traditional approach of packet encapsulation which is CPU intensive and requires constant hardware support and virtual routing.
Cloudistics offers both SDN and network virtualization. For SDN, we use an extension of OpenFlow called CrossFlow, which allows us to control traffic routing centrally from an SDN controller for certain traffic flows, while allowing the built-in protocols in the individual switches to handle the remaining traffic flows. This is a more practical approach, which avoids the need to rewrite all routing protocols with OpenFlow.
For network virtualization, we are the first in the industry to offer the capability to do line-speed network virtualization at Layer 3. Even on a 100 Gb physical network, we can create a 100 Gb virtual network with no perceptible loss of performance, while requiring no special hardware or no changes to network protocols.
With our network virtualization, Cloudistics offers true micro-segmentation. This enables zone defense on a per application basis, thereby containing the effects of any application exploit to only the microsegment on which it occurred. Microsegments are true layer 3 networks and can be setup within 30 seconds. Each microsegment is completely isolated from all other microsegments.
The software that runs inside our virtual networking is the PicOS network operating system, which supports Layer 2, Layer 3, OpenFlow and CrossFlow functionality. We have software that acts as the quorum node for storage HA and we run a DHCP server in the router.
The storage nodes running EBF software check with the Network router every 4 seconds. After 32 seconds, if a possible failure is detected it initiates a controller failover from the active storage controller.
CrossFlow allows us to override standard Layer2/Layer 3 switching/routing protocols for specific traffic flows. Overlay networking allows VMs to communicate using virtual network addressing. A virtual network is overlaid on a physical network.
Virtual network packets are converted to physical network packets, tunneled through the physical network till they reach an endpoint, where they are converted back to virtual network packets and delivered. The overlay network provides the agility needed to support modern applications, the underlay network provides the strength needed in enterprise data centers.
AON handles East-West traffic between compute nodes and North-South traffic from/to compute nodes that are not part of the Cloudistics platform. AON allows networks to be partitioned and isolated using either VLANs or virtual networks (vnets) or both.
You may import existing VMs and VLANs on other infrastructure onto the Cloudistics platform or create up to 64 new VLANs. LAN stretching is possible but not highly optimized, so we encourage the use of vnets.
Function virtualization implements networking functions such as switching, routing and firewalls in software. For each virtual network or vnet the platform automatically creates a special VM called an NFV VM which uses 2 cores and 2 GB of RAM and 2 vNICs, one for internal communication the other to communicate externally.
NFV VM runs DHCP and other networking micro-services. Some networking functions run in every hypervisor. Other functions are implemented in a central NFV VM. We also support custom NFV VMs, including the pfSense open source Firewall.
Cloudistics attaches to a customer’s existing spine/core switch using the well-known Layer 3 BGP, eBGP or OSPF protocols. We only need a range of IP addresses from the customer to use in Cloudistics. A customer can use BGP filters to control traffic from/to Cloudistics. Routing information for newly created virtual networks (or microsegments) is automatically transmitted to the datacenter network through BGP updates. In addition, VRF capabilities will be added later in the year. This enables IP portability and IP address reuse which greatly simplifies MSP’s importing from multiple customers with IP address conflicts.
Yes, you may continue to use your existing physical or virtual firewalls.
Unlike traditional firewalls, Cloudistics employs Distributed Firewalls. As the name suggests, Distributed Firewalls are deployed across the platform on all compute nodes. With distributed authorization, network traffic is no longer evaluated only at one point on the network, but it is now evaluated or authorized at every network endpoint.
Traditional purpose-built networks offer perimeter-based protection, but they cannot guard against threats that may exist within the network. Cloudistics delivers highly granular security controls using Micro-segmentation on a per application basis. Microsegments are true layer 3 networks, offering complete isolation of each microsegment from all other microsegments and providing a zoned defense on a per application basis. With the ability to set up microsegments within minutes, Cloudistics combines ease of use with high levels of control, limiting any effects of application exploits to that application’s microsegment.
Application Security Profiles are defined via a combination of Microsegmentation and Distributed Firewalls. While firewall security policies “allow” or “block” traffic on a given Microsegment [network], Application Security Profiles layer in “allow but scan” rules on top of firewall policy, which invoke scanning of authorized applications for threats, such as viruses, malware, spyware, and DDOS attacks.
How do you offer multi-tenancy without physical clusters or expensive VMware licenses that let you carve physical resources into virtual datacenters?
The core constructs to achieve multi tenancy are through VDC’s and Microsegmentation through our virtual networking. A microsegmented VNET is similar to a truly physically segmented physical network. The only traffic within the network is traffic that belongs to that network.
Any packet tracer such as Wireshark or tcpdump can be used to verify that a microsegmented network is truly secure and segmented.
The operating system used for each SDN router is Pica8. Pica8 implements features and functionality from both Open vSwitch and OpenFlow to create a software-defined networking environment. It supports the less pervasive extension of OpenFlow called CrossFlow which allows us to control traffic routing centrally from an SDN controller for certain traffic flows, while allowing the built-in protocols in the individual switches to handle the remaining traffic flows.
Open vSwitch, sometimes abbreviated as OVS, is an open source implementation of a distributed virtual multilayer switch. The main purpose of Open vSwitch is to provide a switching stack for virtualized environments, while supporting multiple protocols and standards used in computer networks.
OpenFlow conveys forwarding information from a controller to a collection of switches, telling the switches what to do. In return, the switches provide counters and other data to the controller. Because it operates on flows, OpenFlow provides extremely granular control, enabling the network to respond to real-time changes at the application, user and session levels. OpenFlow allows IT to define how traffic should flow through network devices based on parameters such as usage patterns, application needs, service-level agreements and cloud resources.
Cloudistics platform supports the following networking protocols: eBGP, BGP, OSPF & VRRP.
Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the Internet. The protocol is often classified as a path vector protocol but is sometimes also classified as a distance-vector routing protocol.
The Virtual Router Redundancy Protocol (VRRP) is a networking protocol that provides automatic assignment of available Internet Protocol (IP) routers to participating hosts. This increases the availability and reliability of routing paths via automatic default gateway selections on an IP subnetwork.
Two virtual networks can have the same subnet if the customer follows the Cloudistics procedures for isolated private vnets. Isolated private vnets are available in AON 2.0 release.
NSX operates at Layer 2 while AON operates at Layer 3. NSX is a separately priced product that costs 1000s of dollars per node, AON is integrated in the Cloudistics offering. NSX requires hardware support and operates using VxLAN encapsulation. AON needs no hardware support and does not need to perform encapsulation operations.
Cisco ACI consists of three Cisco components: Cisco Nexus 9000 Series switches; a centralized policy management controller called the Cisco Application Policy Infrastructure Controller (APIC); and a Cisco Application Virtual Switch (AVS) for the virtual network edge. The APIC plays the role of an SDN controller but uses a Cisco proprietary API called OpFlex instead of OpenFlow. The Cisco AVS (application virtual switch) does virtual switching and routing and also implements overlay virtualization using the VxLAN tunneling protocol.
AON, as we have described previously, uses a superior approach to network virtualization than the VxLAN approach used in ACI (it is 150x times faster than VxLAN for routing); it works with open network switches, not just Cisco Nexus switches; and it uses an OpenFlow extension called CrossFlow for SDN versus a Cisco proprietary OpFlex API for SDN.
Cloudistics platform offers the ability to create distributed firewalls at Layers 1-4. The following two types of firewalls can be created:
- Virtual Network Firewall – distributed firewall at the virtual network level deployed on each hypervisor within each host.
- Application Override Firewall – distributed firewall deployed for a specific application on each virtual machine.
The source and destination IPs can be a range of IPs or a single IP. The destination IP would be the IP address for the VM that is to have the rule applied. It is the VM that is living within the Cloudistics platform.
- For a group of application VMs that had the app firewall policy attached to them. The destination IP would be a range of IPs that incorporated all the IPs of those VM’s (say for example 10-192.1.10 – 10.192.1.34). We could set the source IP to 0.0.0.0 and the rule set to allow everything as follows.
- The rule would then say, “allow everything to come into the destination IPs of 10.192.1.10 – 10.192.1.34”
Cloudistics utilizes the KVM hypervisor for compute virtualization. Two operating environments are available on the platform:
- Cloudistics Spark OS – based on CentOS 7.3
- Cloudistics Spark OS Guardian Edition – based on RHEL 7.3.
The compute nodes are connected to the top of the rack switch with two 10Gb connections Each compute node utilizes a daughter card for individual connectivity. In an HA configuration with two TOR switches, each 10 Gb link from a blade is connected to a different TOR switch in an active/active redundancy configuration. A minimum of two compute nodes are required, and compute nodes can be scaled to an almost limitless number due to clusterless federation.
Can a customer have diverse types of compute nodes in the same compute block? Does each compute block have to be the same configuration?
A customer can have any type of node within the same stack. Best practice is to have a minimum of two similar nodes for HA purposes to protect against node failures. The workloads are automatically migrated to available nodes in the event of a failure.
Near 100 % utilization is achievable on the compute nodes since Cloudistics is a composable platform with independent scaling of compute nodes and storage resources. Unlike other architectures, Cloudistics uses a very thin storage and NFV vm on the compute nodes, the resources for use by customer applications and thus delivering predictable utilization control.
Cloudistics supports both block and file services.
Cloudistics will support object storage in an upcoming update in late 2018.
Cloudistics Block Services software leverages our elastic block flash technology and runs directly on the storage controllers and does not take up any resources on the compute nodes. Data protection, encryption, global duplication and compression are offloaded to the storage controllers eliminating all pressure on the compute resources. This differentiates us from hyperconverged systems where the storage functions must compete with applications for resources on compute nodes.
Cloudistics File Services are implemented as a service from the application market place and supports NFS (including v4) and SMB (v1, v2 and v3). It’s a complete service including integration with Active Directory and support for very large file shares. It supports the latest CIFS implementation.
When a virtual machine is created and its vdisks are added to an existing storage pool with existing vdisks from other deployed virtual machines, IOPs are evenly distributed across the vdisks in the storage pool. For example, if 2 vdisks are allocated to a storage pool, each has the ability to get 100,000 IOPs. If you add 2 more vdisks to the same storage pool and block, each vdisk is now capable of 50,000 IOPs.
The storage controllers are set up in an active-passive configuration.
Cloudistics supports global deduplication, compression and thin provisioning.
Cloudistics supports single-instancing for data reduction, in addition to dedupe. To explain single instancing, consider an application where there are many VMs, with small differences between each VM. The first copy of the VM becomes the golden master. Single instancing is the capability of creating multiple clones off a golden image with pointer-based technology. Original data is seen by all clones using pointers and only unique/different data is written to the storage block, so data is only stored once.
We implement data at rest encryption through software and transparently to the user, utilizing the latest 256-bit AES-XTS standard. This makes us FIPS 140-2 compliant. All data is encrypted all the time by default. To enable businesses to safeguard their data to meet their organizational security and compliance requirements, Cloudistics encrypts all data residing in the storage pool by default. This way all data residing in the storage pool is automatically encrypted prior to persisting to storage and decrypted prior to retrieval. The encryption, decryption, and key management are totally transparent to users. Cloudistics at rest data encryption is FIPS 140-2 compliant. Additionally, Cloudistics also supports external KMIP-compliant key management services such as SafeNet or Vormetric to manage encryption keys.
Do you support Copy Data technology and how does it work?
Copy data management eliminates data copies, when the same disk (or data) needs to be modified by more than 1 VM. Cloudistics automatically determines which disks have been laid out in the past and internally does copy data management by cloning such disks for reuse. Cloned disks behave exactly like their original counterparts – they are readable and writable. Most importantly cloned disks have the same performance (IOPS, bandwidth) as the original disks, and hence can be used for production workloads.
We implement a RAID 50 when the storage block consists of more than 8 drives. If a storage block only has 8 drives, then a RAID 5 will be applied. Two hot spares are also provided across the group of drives in a Storage block, so data rebuild can start instantly when a drive fails.
Yes, our enterprise drives include erasure coding within them to provide data protection at the sector level which protects against failure due to excessive wear. We leverage RAID-5 as an extra level or protection at the disk level.
Storage is direct block access through an iSCSI initiator on the VM. Each VM has a vDisk that is mapped to an iSCSI LUN with 4 paths utilizing MPIO directly from the storage Block. A vDisk must fit entirely inside a Storage Block.
The storage blocks are connected to the interconnect through a 10Gb connection.
Storage blocks can contain the maximum amount drives per block before having to scale out with another block. Conservatively, with thin provisioning, de-dup, compression and single instancing, a factor of 5x reduction is possible when compared to bare-metal.
Once a block is full, new blocks can be added and federated with each other into storage pools. Cloudistics can scale storage to 100 of PB’s with each block delivering 200K IOPS, 4 GB/sec, and 125 µs latency. When designing a system, make sure to account for the additional port on the top of the rack switch.
If a VM has multiple SCSI drives attached to it for performance reasons on the current infrastructure, how does Cloudistics migrate the VM?
Cloudistics storage being all flash, we believe that the consolidation of the SCSI disks to a single flash drive can be accomplished while providing better performance.
Cloudistics converts a VMDK to a KVM template through an automated process. All of the drives attached to the VMDK are converted. However, an iSCSI disk which is mapped to the VM utilizing the OS’s iSCSI Initiator, is not visible from a VMDK import. To convert multiple disks, the process is:
- Import the VM in the current state with the network connectivity open to see the existing storage so the sessions stay connected.
- Create multiple vdisks for the VM from the Cloudistics platform.
- Utilize the OS’s volume manager for replication between vdisks to bring the data over from the iSCSI volumes to the vdisks on Cloudistics.
VMs can directly attach to external iSCSI or NFS/CIFS storage simply by connecting to it from the guest VM.
Cloudistics leverages the Q-Star application to archive data to archive media or AWS. Simply run the application from our marketplace and follow the configuration steps to assign a slice of storage from our platform. Then you point the Q-Star service to an iSCSI archive target or AWS. You then determine the size of the volume that is presented to the application. It then uses our block storage as a cache, and then archives off the data at the block level to the backend archive storage.
How does Cloudistics leverage its copy data technology and cloning to reduce the R-factor for Hadoop workloads?
Many big data implementations are bare-metal servers with direct attached storage. This architecture requires the data to be replicated 2x-3x times for protection. With Cloudistics, we use RAID, so the R-factor reduces from 2-3x to 1. In addition, our copy data cloning capabilities eliminate copy time and storage waste when scaling out Hadoop nodes. These two built-in capabilities drive down storage costs and help improve performance.
No, Cloudistics does not need worker VM’s like Nutanix (CVM) and Cloudistics does NOT perform storage functions on the compute nodes. Nutanix claims 25% overhead and up to 64GB of RAM for CVM deduplication. This is a large burden to the system. The Nutanix deduplication is not global across nodes, just local to the VM’s on the node. Nutanix overheads are even higher with erasure coding.
Yes. Cloudistics includes a built-in image backup system that create point-in-time and application consistent snapshots. The snapshot can be maintained locally or asynchronously replicated to a remote site. VM level image recoveries are as simple as booting the point in time snapshot. Very granular retention policies are supported allowing up to 7 years of backup archives. File level recovery is supported by simply mounting the snapshot and extracting files.
Cloudistics does regular backups of both the Ignite Management Portal and platform storage data and we retain multiple copies. We backup our portal and data every 4 hours. The backups are encrypted and on average take 500 MB of space. We are currently retaining these backups. Cloudistics supports all agent-based products such as Commvault, Veeam, Rapid Recovery and NetBackup.
As low at 1 minute but 15 minutes is recommended for optimum performance.
Simply select the recovery point from the list and select recover. The virtual machine will be restored to its previous state.
To copy a file from a backup, simply start a new VM from the snapshot and copy the file to a CIFS share that can be accessed from the destination location.
Yes, robust and customizable retention policies are supported. Backups can be stored for up to 7 years.
Yes, all backups are compressed and deduped transparently to the backup process.
Yes, all backups are encrypted and the decryption and key management is transparent to users.
We support a very comprehensive retention policy for snapshot retention. You may specify how many snapshots to keep at the remote site, daily, weekly, monthly and yearly and the system automatically does the roll-up. A sophisticated capability called “Clone and Attach” is also provided.
This allows you clone a vDisk or a snapshot vDisk from one VM and attach it to the same or a second VM. Clone and Attach is fast and only minimally impacts storage consumption.
Cloudistics supports disaster recovery by replicating the application aware snapshots from a local site to a remote location.
You can choose a location from over 60 sites worldwide to store backups and to provide public cloud disaster recovery services. We use a standard encrypted SSL handshake to authenticate with cloudistics.com, before sending any data out.
Cloudistics offer Cloudistics Spark OS powered by CentOS, and Spark Guardian Edition OS powered by RHEL 7. As the OS for our compute node and storage controllers, both editions provide the performance and flexibility you expect from Cloudistics. However, in contrast to Spark, the Spark Guardian Edition addresses specific certification requirements for government use. Be certain to consult a Cloudistics Sales Engineer for details.
Cloudistics uses 2FA security measures to prevent unauthorized access to user accounts in the SaaS management portal. These two factors typically include something you know (e.g., a password) and something you have (e.g., a code sent to a mobile device). By requiring more than one factor during the authentication process, there is increased assurance the user’s access is authorized.
Cloudistics uses a third-party security audit organization to perform regular penetration testing to ensure critical security tests are performed by experienced and skilled auditors from outside the company. The 3rd party organization we use also does penetration testing for the Government and for many Fortune 500 companies. Each audit helps determine the extent of vulnerabilities not detected through regular in-house audits. As well, the audits gauge the adequacy of incident management procedures and performance of the incident management team.
Cloudistics natively integrates its high-performance storage directly with Docker containers. Cloudistics offers persistent block storage directly accessible by the container. The persistent storage enables the Docker Swarm and Kubernetes auto scaling and HA capabilities out of the box.
Cloudistics offers a simple, single, premium level of proactive alert services for all software and hardware, including user, technical and maintenance support, which we call EarlyInsightupport. We offer either a 3 or 5-year support option as a suite of services that comes standard with each system. Each customer receives personal and interactive support to solve technical questions quickly via our team of experts, who are available via online chat, email, and phone. All hardware comes with next day field replacement, however, the option of 4-hour replacement is available as an optional hardware support upgrade that includes the same “white-glove” attention provided during platform deployment.
Cloudistics support requests prioritized based on the business impact of the issue. Technical support requests within a severity level are generally processed on a first-come, first-served basis. Critical (Sev 1) and Significant (Sev 2) business impact requests that require immediate response or direct help of technical support specialists may be processed out of turn.
Our response times, status cadence, support effort and resolution targets are defined by ticket severity type, as outlined below.
|Severity||Sev 1||Sev 2||Sev 3|
|Initial Response||Within one hour after first contact||Within 2 hours after
|Within 1 business day after first contact|
|Status Updates||Every 2 hours||Each business day||As needed or as status changes|
|Support Effort||7X24 continuous until interim fix provided||5X9 continuous||As required to meet resolution target|
|Resolution Target||Within 24 hours||Within 7 calendar days||Within 14 calendar days|
As a Cloudistics customer, you have access to a support feature which has proven to be highly acclaimed by our customer base. Real-time chat is available during business hours, 9-5 EST. A user can either initiate a session from our Support page on our website, or more conveniently, directly from the Ignite Cloud Controller user interface. Outside of these hours, initiating a support chat will flow the user to call our TFN (for service-affecting issues), or to a simple form which will generate an email and open a ticket (for non-service-affecting issues or inquiries).
Support Mode sessions are conducted while the User is logged into their Ignite Cloud Controller and engaged with a Cloudistics Support Engineer over the phone. Cloudistics Support Mode uniquely provides a fully secure, Customer-controlled access method for the Cloudistics Services Team to a Customer’s Cloudistics Platform. Cloudistics Support Mode can only be initiated by the Customer’s authorized user (‘User) from a session in their Ignite Cloud Controller, and never by Cloudistics.
Full control of the secure connection is retained by the User while utilizing Cloudistics Support Mode:
(1) He or she explicitly and exclusively initiates Cloudistics Support Mode;
(2) the User Ignite Cloud Controller session persistently displays when Cloudistics Support Mode in “On”; and at any time, the User can disable it, resulting in an automatic tear down of the secure session between the Cloudistics Support Engineer and the User’s Cloudistics On-Premise Platform.
One major benefit of Cloudistics is that we own and are fully responsible for the entire hardware and software stack. A Customer never interfaces with the hardware OEM for any reason what so ever. We are the front line for all hardware support, and dispatch either an OEM resource or Cloudistics Field Engineer when replacing a failed component. Similarly, all related firmware and OEM-specific software support is handled by Cloudistics.
Support for Third Party Applications: Cloudistics expects its customers to run third-party workloads on the Cloudistics platform, including but not limited to Linux and Windows based applications and virtual appliances. These may be installed by the customer or deployed from the Cloudistics Application Marketplace.
Cloudistics Support will help in isolating the issue between the Cloudistics platform and the application. Full technical support will be provided if the issue is determined to be caused by the Cloudistics platform. Commercially reasonable support will be provided to all other scenarios. When an adequate solution to your issue is not achieved, you might be referred to other support channels that are available for the non-Cloudistics software.