We are not stopping with the integration around and above Kubernetes

To improve competitiveness in a fast-paced world, organizations are embracing software as a prime differentiator. A software-driven business is more agile and efficient, innovates faster and responds dynamically to changing market and customer demands. Increasingly, gaining these compelling advantages requires adopting cloud-native applications.

Kubernetes is the de facto standard for container orchestration for microservices and applications. However, enterprise adoption of big data and databases using containers and Kubernetes is hindered by multiple challenges, such as complexity of persistent storage, availability, and application life-cycle management. Kubernetes provides the agility and scale that modern enterprises require. However, Kubernetes provides the building blocks for infrastructure, but not a turnkey solution.

Originally containers and Kubernetes were optimized for stateless applications, restricting enterprises to use container technology for workloads, such as websites and user interfaces. More recently, stateful workloads have been increasingly run on Kubernetes. Whereas it is relatively easy to run stateless microservices using container technology, stateful applications require slightly different treatment.

There are multiple factors which need to be taken into account when considering handling persistent data using containers, including:

• Containers are ephemeral by nature, so the data that needs to be persistent must survive through the restart/re-scheduling of a container.
  
• When containers are rescheduled, they can die on one host, and might get scheduled on a different host. In such cases, the storage should also be shifted and made available on a new host for the container to start gracefully.
  
• The application should not have to deal with the volume/data and underlying infrastructure, and should handle the complexity of unmounting and mounting, etc.
  
• Certain applications have a strong sense of identity (such as Kafka, Elastic, etc.), and the disk used by a container with a specific identity is tied to it. If, for any reason, a container with a specific identity becomes rescheduled, it is important that the disk specifically associated with that identity, gets reattached on a new host.
  

In this white paper, we present a solution that provides the robust capabilities and built-in high availability and scalability of XtremIO and PKS, bringing simplicity to Kubernetes, and creating a turnkey solution for data-heavy workloads. XtremIO CSI Plugin provides Pivotal PKS technology with built-in enterprise-grade container storage and uncompromising performance that extends Kubernetes’ multi-cloud portability to the private cloud.

With this proven integration, organizations can accelerate their digital business objectives via cloud-native applications, from development through testing and into production, on a single platform with ease and agility. Most importantly, eliminating the risk of application downtime preserves critical revenue streams, helps ensure customer satisfaction and strengthens your competitive advantage.

Planning, designing and building a private or hybrid cloud to support cloud-native applications can be a complex and lengthy project that does not address immediate business needs. IT also must maintain and manage the infrastructure that supports these new applications, to ensure that the environment is reliable, secure and upgradeable.

Kubernetes offers great capabilities. However operationalization of these capabilities is not a trivial task. There are many layers involved, such as hardware, operating system, container runtime, software-defined networking, and Kubernetes itself. And all the layers require Day 0, Day 1 and Day 2 activities. Most of these layers also require constant patching (for example, Kubernetes ships a new version every three months), so the effort to maintain this infrastructure grows exponentially.

Kubernetes is the de facto standard for container orchestration platforms. However, Kubernetes can be difficult to operationalize and maintain for the following reasons:

• High availability — There is no out-of-the-box fault-tolerance for the cluster components themselves (masters and etcd nodes).
  
• Scaling — Kubernetes clusters handle scaling the pod/service within the nodes, but do not provide a mechanism to scale masters and etcd Virtual Machines (VMs).
  
• Health checks and healing — The Kubernetes cluster performs routine health checks for node health only.
  
• Upgrades — Rolling upgrades on a large fleet of clusters is difficult. Who manages the system it runs on?
  
• Operating systems — A Kubernetes installation requires multiple machines where an OS is installed. Installing and patching these systems is an overhead.
  

Pivotal Container Service (PKS) is a purpose-built product that enables enterprises to deploy and consume container services with production-grade Kubernetes, built with high availability, security, multi-tenancy and operational efficiency across private and public clouds.

It effectively solves the complexities around Kubernetes infrastructure and enables you to focus on your business applications. Furthermore, it benefits your developers, providing them with the latest version of Kubernetes and simple integrations with monitoring and logging tools.

Key Benefits

With Pivotal Container Service (PKS), not only do you receive a vanilla Kubernetes distribution supported by Pivotal and VMware, but you also receive the automation to maintain the Kubernetes stack with reduced effort, including the operating system, container runtime, software-defined networking and Kubernetes itself. The automation provided by BOSH enables you to install (Day 0), configure (Day 1), patch and maintain your Kubernetes infrastructure in a healthy state over time (Day 2).

This automation also extends your capabilities to have an effective Kubernetes as a service offering, and lets you create Kubernetes clusters with a single command, to either expand or shrink the clusters, or to repair them as needed. This is a unique capability that enables you to provide your Kubernetes users with as many clusters as they need, and to resize them, leveraging automation as your workload requirements change.

PKS also simplifies the networking configuration, by providing you with VMware NSX-T, which is a software-defined network infrastructure to build cloud-native application environments.

PKS also provides you with a container registry to host your containers, namely, Harbor, a graduated CNCF project.

1. Pivotal PKS Components
   

Dell EMC XtremIO X2: The Next Generation All-Flash Array

Dell EMC XtremIO is a purpose-built all-flash array that provides consistent high performance with low latency; unmatched storage efficiency with inline, all-the-time data services; rich application integrated copy services; and unprecedented management simplicity.

The next-generation platform, XtremIO X2, builds upon unique features of XtremIO to provide even more agility and simplicity for your data center and business. Content-aware in-memory metadata, and inline all-the time data services have made XtremIO the ultimate platform for virtual server and desktop environments and workloads that benefit from efficient copy data management. The architecture offers VMware XCOPY operations that are twice as fast, which can reach as high as 40 GB/s bandwidth, due to them being in-memory operations.

X2 includes inline, all-the-time data services, thin provisioning, deduplication, compression, replication, D@RE, XtremIO Virtual Copies (XVC), and double SSD failure protection with zero performance impact. Only XtremIO’s unique in-memory metadata architecture can accomplish this.

This white paper is designed for developers, system architects and storage administrators tasked with evaluating or deploying Pivotal PKS, and interested in persistent storage within their deployment. While this document focuses on Dell EMC XtremIO X2 products, the concepts discussed and implemented can be applied to other storage vendor products.

Understanding the material in this document requires prior knowledge of containers, Kubernetes, PKS and of the Dell EMC XtremIO X2 cluster type. These concepts are not covered in detail in this document. However, links to helpful resources on these topics are provided throughout the document and in the References
section. In-depth knowledge of Kubernetes is not required.

Click the screenshot below to download the white paper.

You can also watch the below demos to see how it all works

Back in DTW, we have made a commitment to invest in the kubernetes eco-system (which is getting bigger and bigger..)

Every journey starts with small steps and if you are new to the who ‘storage persistency’ issues with Docker, I would highly advice that you first read the post I wrote back in november 2018

https://xtremio.me/2018/12/13/tech-previewing-our-upcoming-xtremio-integration-with-kubernetes-csi-plugin/ read it? Good! so after we have released the VxFlex OS and the XtremIO CSI plugins, it is now the time for PowerMax to get the support as well.

If you think about it, PowerMax is the only array that support both Mainframes and (now), containers. Think of all the mission critical apps it support and now, all the new Devops based apps as well, it can really do it all!

About the support for the PowerMax / CSI initial release:

The CSI Driver adheres to the Container Storage Interface (CSI) specification v1.0 and is compatible with Kubernetes versions 1.13.1, 1.13.2, and 1.13.2 running within a host operating system of Red Hat Enterprise Linux (RHEL) 7.6.

Services Design, Technology, & Supportability Improvements

The CSI Driver for Dell EMC PowerMax v1.0 has the following features

• Supports CSI 1.0
  
• Supports Kubernetes version 1.13.1, 1.13.2, and 1.13.3
  
• Supports Red Hat Enterprise Linux 7.6 host operating system
  
• Supports PowerMax – 5978.221.221 (ELM SR)
  
• Persistent Volume (PV) capabilities:
  
  • create
    
  • delete
    
• Dynamic and Static PV provisioning
  
• Volume mount as ext4 or xfs file system on the worker node
  
• Volume prefix for easier LUN identification in Unisphere
  
• HELM charts installer
  
• Access modes:
  
  • SINGLE_NODE_WRITER
    
  • SINGLE_NODE_READER_ONLY
    

Installation

Driver Installation Prerequisites

Full details are in the Installation Guide but here is a summary of pre-reqs for the driver.

• Upstream Kubernetes 1.13.x, with specific feature gates enabled
  
• Downstream distributions, like OpenShift and PKS, have not been tested and may not work at this time.
  
• Docker daemon running and configured with MountFlags=shared on all k8s masters/nodes
  
• Helm and Tiller installed on k8s masters
  
• iscsi-initiator-utils package installed on all the Kubernetes nodes
  
• Make sure that the ISCSI IQNs (initiators) from the Kubernetes nodes are not part of any existing Hosts on the array(s)
  
• A namespace “powermax” should be created prior to the installation. The driver pods, secrets are created in this namespace.
  
• Make sure that all the nodes in the Kubernetes cluster have network connectivity with the U4P instance (used by the driver)
  

Full details are in the Installation Guide.

1. Clone the repository from the URL – github.com/dell/csi-powermax
   
2. Create a Kubernetes secret – “powermax-creds” – with your U4P’s username and password in the namespace “powermax“
   
3. (Optional) Create a Kubernetes secret – “powermax-certs” – with CA cert(s) used to sign U4P’s SSL certificate. If not found, the install script will create an empty secret in the namespace “powermax“
   
4. Create your myvalues.yaml file from the values.yaml file and edit some parameters for your installation.These include –
   
   1. The U4P URL (must include the port number as well)
      
   2. clusterPrefix – A unique identifier identifying the Kubernetes cluster (max 3 characters)
      
   3. A list of port group names
      
   4. An optional (white)list of arrays the driver will manage
      
   5. A set of values for the default storage class (SYMID, SRP, ServiceLevel)
      
5. Run the “install.powermax” shell script
   
6. Customize the installation (if desired) by adding additional Storage Classes to support multiple arrays, storage resource pools, service levels
   

Using the Driver

See the Installation Document section “Test Examples that use the CSI Driver For Dell EMC PowerMax”

• There are a number of test helm charts and scripts in test/helm that can be used as examples of how to deploy storage using the driver

• Create a “test” namespace to hold the tests.
  
• The directory 2vols contains a simple Helm chart that deploys a container with two volumes. To deploy it run “sh starttest.sh 2vols”. To stop it run “sh stoptest.sh”.
  
• There is a sample master/slave Postgres deployment example.
  

  ▪ Deploys a master/slave postgres database ▪ You can deploy it using “sh postgres.sh”; however for the script to work correctly you need psql locally installed where you’re running the script from, and the world database from http://pgfoundry.org/projects/dbsamples/
  installed at /root/dbsamples-0.1.
  

  ▪ If psql and the sample database are installed, the script will install the sample database into the deployed postgres database and run a sample query against it.
  

Documentation and Downloads

CSI Driver for Dell EMC PowerMax v1.0 downloads and documentation are available on:

Github:  https://github.com/dell/csi-powermax

Docker Hub:
https://hub.docker.com/r/dellemc/csi-powermax

Below you can see a quick video that was done with the tech preview of the plugin

We have just released the 4.0 version of the plugin, I’m thankful for all the customers that are using it and showing us that the way forward is to automate everything!

This version brings the support for XIOS 6.3 as well as additional workflows for native replication and QoS. we have also introduced the concepts of low-level objects which greatly expands what can be done in vRO with XtremIO Storage.

In this release, there’re about 180 predefined workflows within XtremIO vRO plugin, including array configuration, storage provisioning, storage management, and vSphere-integrated workflows.

This allows users and storage admins to complete most common storage operations from vRealize Orchestrator automatically well as integrating those existing workflows and actions to create customized workflows, and by doing so, to handle both day I and day II operations to meet your specific automation needs, without the need to login to each storage array.

You can download the workflow user guide from https://support.emc.com/docu92210_XtremIO_Plugin_for_VMware_vRealize_Orchestrator_4.0.0_Workflows_User_Guide.pdf?language=en_US&source=Coveo

And the installation and configuration guide from https://support.emc.com/docu92209_XtremIO_Plugin_for_VMware_vRealize_Orchestrator_4.0.0_Installation_and_Configuration_Guide.pdf?language=en_US&source=Coveo

You can download the new plugin by clicking the screenshot below

You can watch a short recording of a workflow and it’s integration to vRA here

and a longer (more detailed) one, here

We have just released a minor update to the new(ish) HTML5 based vCenter plugin, if you are new to this, I highly suggest you first read this post I wrote here https://xtremio.me/2018/12/14/vsi-virtual-storage-integrator-8-0-is-here/

This section provides a list of features supported in this release.
VSI 8.1 release supports the following features:

VMAX All Flash/PowerMax support:
Storage System and Storage Group Administration
Provisioning VMFS Datastores
Viewing VMFS DatastoresRDM creation on VMAX All Flash/PowerMax
View VM disk information for VMAX All Flash/PowerMax
VMAX All Flash/PowerMax Host Best Practices

XtremIO support:
Storage System Administration
Provisioning VMFS Datastores
Viewing VMFS Datastore Details
Increase VMFS Datastore capacity
RDM creation on XtremIO
View VM disk information for XtremIO
XtremIO Host Best Practices

Unity support:
Storage System and Storage Pool Administration
Provisioning VMFS Datastores
Viewing VMFS Datastores
Provisioning NFS Datastores
Viewing NFS Datastores
Increase NFS and VMFS Datastore capacity
RDM creation on Unity
View VM disk information for Unity
NAS Server Administration
Unity Host Best Practices
Users/User Group Administration

To download the new client, click the screenshot below

And you can download the documentation, clicking this url https://support.emc.com/docu94130_VSI_for_VMware_vSphere_Client_8.1_Product_Guide.pdf?language=en_US&source=Coveo

One more thing..

We are starting to containerize some of our data services, this statement is pretty vague deliberately but in the context of the VSI plugin, lets assume you are already running VSI 8.0 and want to do an upgrade to VSI 8.1, you have two options:

Upgrade VSI Plug-in using DockerHub
Use the procedure in this topic to upgrade the VSI plug-in using DockerHub.
Before you begin
You must log out of the vCenter before upgrading the plug-in.
Procedure
1. Login to the IAPI VM through SSH.
2. Stop the current IAPI container. Use the following command: docker stop iapi
3. Pull the latest IAPI/VSI image from DockerHub: docker pull dellemc/vsi
4. You can also perform the following optional steps:
a. Backup the previous IAPI container. Use the following commands:
a. docker rename iapi iapi-before-upgrade

b. docker update –restart=no iapi-before-upgrade
b. Backup the IAPI database. Use the following command:
docker cp vsidb:/data/appendonly.aof <OUTPUT_DIRECTORY>
c. Backup the existing VSI plug-in. Use the following command:
cp /opt/files/vsi-plugin.zip <OUTPUT_DIRECTORY>
d. Backup existing SSL certificates. Use the following command:
docker cp iapi:/etc/ssl/certs/java/cacerts
<OUTPUT_DIRECTORY>
e. Any files backed up in the previous steps can be restored after the container
upgrade if needed by copying the files to the new container. For example,
docker cp <OUTPUT_DIRECTORY>
5. Upgrade the VSI plug-in.
l To register the VSI plug-in without SSL verification, use the following
command:
python3 /opt/scripts/register_extension.py -ignoressl true
l To see additional options for using SSL certificate verification during
registration, use the following command:
python3 register_extension.py -h
Note
After upgrade, the SSL is not enabled by default. To enable SSL, see Change Settings in application.conf of the IAPI container.
6. Refresh the VSI plug-in:
l If you have a current vCenter already open, logout and log back in to refresh
the plug-in.
Or
l If you do not have a vCenter open, log in to the vSphere Client, log out, and
log back in to refresh the plug-in.
Upgrade VSI using Package
Use the procedure in this topic to upgrade VSI 8.0 to VSI 8.1 version.
Before you begin
You must log out of the vCenter before upgrading the plug-in.

Procedure
1. Download the VSI 8.1 upgrade.tar package from Dell EMC Support Site or DockerHub.
2. Copy the upgrade package to /tmp folder of the IAPI server.
To copy the upgrade file, use the following command:
scp iapi-vsi-upgrade.tar root@<IAPI server>:/tmp
Note
If SSH is enabled, the default password is root.
3. Change the directory to /tmp folder.
4. Extract the upgrade package. Use the following command:
tar -xf/tmp/<iapi-vsi-upgrade.tar>
Note
The upgrade package contains the .tar file, the upgrade script, and the docker
image.
5. Run the upgrade script. Use the following command:
./upgrade_iapi.sh –upgrade <iapi-vsi-upgrade.tar.gz>
The upgrade script backs up and renames the VSI 8.0 docker image, lay down
the new docker image. The script also restores the necessary files to a backup
folder. An example for the folder name, <iapi-beforeupgrade-20190412194829>

Note
You can also restore the application.conf and SSL certificates after the
completion of upgrade. Use the restore command with the .tar file that resides
in the backup folder:
./upgrade_iapi.sh –restore ./<20190412194829.tar>
6. To upgrade the VSI plug-in, use the following command:
python3 /opt/scripts/register_extension.py -ignoressl true
Note
After upgrade, the SSL is not enabled by default. To enable SSL, see Change
settings in application.conf of the IAPI container.

VMware have just released a new version of SRM (8.2), it’s a pretty big release because for the first time, the SRM server itself can now run within an photon OVA as oppose to the windows server it had to run in previous version. You may ask yourself what’s the big deal, well:

• You can now save on the windows server licensing costs.
• Deployment is a breeze.
• Updates to the SRM software will be literally a click of a button.

But that’s only one big change, the other one, is that now, the SRA (storage replication adapter) which is the glue between vCenter to the storage array is actually running as a docker image Inside the SRM appliance. Here at Dell EMC we were busy working on it and I’m proud to announce the day 0 support for SRM 8.2 and our XtremIO & Unity arrays (other arrays will follow shortly).

Apart from the SRA support, we have also certified our unique pit (point in time) integration with SRM 8.2, this feature will allow you to specify a specific pit to test or failover to when using SRM, think about it, let’s say you have a logical data corruption or a malware infection etc, it’s not enough to run a failover to the DR site, you want to actually failover to a point in time BEFORE the data corruption and we provide you just that with XtremIO, SRM and our free vCente plugin (VSI 7.4)

You can download SRM 8.2 clicking the screenshot below

You can download the new SRAs (one for the classic windows SRM or the new, photon based SRA) from clicking the screenshot below

And finally, you can download the VSI plugin from here (click the screenshot below)

Below you can see a demo showing you how it all works

Back in august 2018, I blogged about CloudIQ that now support XtremIO, if you are new to CloudIQ, I highly encourage you to first read the post here

https://xtremio.me/2018/08/27/vmworld-2018-xtremio-integration-with-cloudiq/ but in a nutshell, CloudIQ is the Software as a Service (SaaS) platform offered by Dell EMC that allows customers to manage all of their EMC arrays in a single pane of management. A Dell EMC customer needs to simply log into the CloudIQ application, and he will automatically be presented with an Overview of all of the Dell EMC arrays deployed

now, since CloudIQ IS a SaaS based application, we have updated it monthly since august 2018 with new features, here what’s new based on the month / XtremIO releases:

Wednesday, October 17, 2018 – CloudIQ now has a unified Alert View

We’ve consolidated alerts from different product types into a single alert log, and added support for XtremIO systems. Now you can view alerts from all monitored systems in one single view. In the Alert view, clicking the “Refine” button now includes filtering alerts based on product family and model.

Thursday, November 1, 2018 – New Mobile App

Monitoring Dell EMC storage systems just got easier – CloudIQ’s mobile application is now LIVE in the Apple App and Google Play stores! CloudIQ customers, trusted advisors and partners can now receive notifications about changes in users’ storage environments, view health details, and forward issues to others. Make sure to download the CloudIQ App now!

Tuesday, November 6, 2018 – Management Software Upgrade Indications

You will now see an indication when a VMAX or XtremIO storage system has a management software update available. These indications are visible in the system details Configuration tab for VMAX and XtremIO storage systems. Clicking the ‘Learn More’ link will open a dialog with summary information and relevant links to support resources.

Wednesday, November 14, 2018 – CloudIQ now supports XtremIO Hosts

In the Hosts listing page, users can now view XtremIO hosts. In a Host’s details page, users can see the Host’s attributes, including Volumes and Initiators related to the Host.

Wednesday, November 14, 2018 – Capacity prediction for XtremIO systems

We’ve added Capacity Prediction support for XtremIO. The System historical capacity chart displays Actual Free and Used Capacity. The prediction provides Forecasted Free and Used capacity with the Confidence range. Users can also optionally display Provisioned capacity as a reference.

Thursday, February 28, 2019 – Display Data Reduction Chart for XtremIO systems

This new chart in the System Details Capacity Tab for XtremIO systems visualizes deduplication and compression ratios of the system.

Tuesday, March 26, 2019 – XtremIO Anomaly Support

We’ve added support for anomaly detection on XtremIO systems. You can now view a range of statistically normal behavior for each of your systems’ performance metrics on the system Performance details page. Based on a rolling three week analysis per metric, the metrics charts visuals now highlight an anomaly any time the metric breaches the normal range within the last 24 hours

Tuesday, March 26, 2019 – Enhanced Storage Object Activity on XtremIO System Performance Page

We’ve expanded the scope of the Storage Object Activity lists on the Performance details pages for XtremIO systems. You can now explore all of your system’s volumes with a paginated list, sorted by the highest average activity over the last 24 hours.

Thursday, April 18, 2019 – VMware XtremIO Integration

Added VMware support for XtremIO systems in CloudIQ. Now you can get details about virtual machines in your XtremIO storage environment including performance and capacity at the VM level. To enable VMware data collection, you must first deploy and configure the new CloudIQ Collector vApp which is accessed directly from CloudIQ.

Thursday, April 18, 2019 – New Volume Properties View for XtremIO Systems

We’ve added a Volume Properties page for XtremIO systems. You can view a Volume’s attributes, including Hosts and Consistency Groups related to the Volume, from either the System Configuration Details view or the Host Details view of an XtremIO system.

Wide distribution of Data for Massive Performance

Flex widely distributes data across all storage resources in the cluster, which eliminates the architectural problems of other IP-based storage systems.  With VxFlex OS, ALL of the IOPS and bandwidth of the underlying infrastructure are realized by a perfectly balanced system with NO hot spots.

Massive Availability and Resiliency

Flex has a self-healing architecture that employs many to many, fine-grained rebuilds, which is much different than the serial rebuilds seen with most storage products. When hardware fails, data automatically rebuilt using all other resources in the cluster. This enables a 6×9’s availability profile while using x86 commodity hardware.  Flex can rebuild an entire node with 24 drives in mere minutes – a fraction of the time it takes to rebuild a single drive on a traditional array.

Built In Multipathing

Flex automatically distributes traffic across all available resources. Every server can be a target as well as an initiator.  This means as you add/remove nodes in the cluster, multipathing is dynamically updated on the fly.  Inherent, dynamic built-in multipathing.

Dell EMC VxFlex Ready Nodes converge storage and compute resources into a single layer architecture, aggregating capacity and performance with simplified management capable of scaling to over a thousand nodes. VxFlex OS provides the maximum in flexibility and choice. VxFlex OS supports high performance databases and applications,
at extreme scale (again from as little as 3 nodes to over 1000 per cluster) and
supports multiple OS, Hypervisors or Media. You can build the infrastructure that best supports your applications. Choose your hardware vendors or use what you already have in house.

TWO LAYER-

• Similar structure to traditional SAN
• Supports organizations who prefer separation between storage and application teams
• Allows scaling of storage needs separately from the application servers
• New 100Gb Switch for aggregation layer

Or

HCI

• Provides maximum flexibility and easier to administrate
• Servers host both applications and storage
• Modern approach to manage IT Data Center
• Provides maximum flexibility and easier to administrate
• Maintenance of servers impact both storage and compute

In a Storage-only Architecture:

The SDC exposes VxFlex OS shared block volumes to the application.

• Access to OS partition may still be done “regularly”
• VxFlex OS data client (SDC) is a block device driver

The SDS owns local storage that contributes to the VxFlex OS storage pool

• VxFlex OS data server (SDS) is a daemon / service

IN two-layer, SDC and SDS run on different nodes and can grown independent of each other

We have just released VxFlexOS 3.0 which includes many asked features, here’s what’s new

Fine Granularity (FG) Layout

Fine Granularity layout (FG) – a new, additional storage pool layout using a much finer storage allocation units of 4KB. This is in addition to existing Medium Granularity (MG) storage pools using a 1MB allocation units.

4KB allocation unit allows better efficiency in thin-provisioned volumes and snapshots. For customers that frequently use snapshots, this layout will create significant capacity savings.

Note: FG storage pools require nodes with NVDIMMs and SSD/NVMe media type

Inline compression – Fine Granularity layout enables data compression capability that can reduce the total amount of the physical data that needs to be written to SSD media. Compression saves storage capacity by storing data blocks in the most efficient manner, when combined with VxFlex OS snapshot capabilities, can easily support petabytes of functional application data.

Persistent Checksum – In addition to the ‘inflight checksum’ available, persistent checksum presents an added data integrity for the data and metadata of FG storage pools.  Background scanners monitor the integrity of the data and metadata over time.

VxFlex OS 3.0 introduces an ADDITIONAL, more space efficient storage layout

Existing – Medium Granularity (MG) Layout
• Supports either thick or thin-provisioned volumes
• Space allocation occurs at 1MB units
• No attempt is made to reduce the size of user-data written to disk (except with all-zero data)
Newly Added – Fine Granularity (FG) Layout
• Supports only thin-provisioned, “zero-padded” volumes
• Space allocation occurs at finer 4KB units
• When possible, reduces actual size of user-data stored on disk
• Includes Persistent Check-summing for data integrity
A Storage Pool (SP) can be either a FG or MG type
• FG storage pools can live alongside MG pools in a given SDS
• Volumes can be migrated across the two layouts (MG volumes zero padded)
• FG pools require SSD/NVMe media and NVDIMM for acceleration

Inline Compression

• Compression algorithms in general
• What’s desirable is something off-the shelf, standard, field-proven
• Lempel-Ziv (LZ) based compression (recurring patterns within preset windows) w/wo Huffman coding
• Very good for compression: Text (>80%), DB (~70% [ranges from 60% – 80%] )
• The algorithm used in VxFlex OS 3.0 is C-EDRS,
• DellEMC proprietary (similar to LZ4). The same algorithm that XtremIO uses
• Good balance of compression ratio and performance (light on CPU)
• We test compressibility in-line (on the fly)
• Some data is not a good candidate for compression (e.g. videos, images, compressed DB rows)
• Invest CPU cycles up front. If not reducible more than 20%, consider incompressible and store uncompressed
• Don’t waste CPU cycles later decompressing read IOs

Persistent Checksum
• Logical Checksum (protects the uncompressed data)
• All data written to FG pools, with or without compression, have a logical checksum always calculated by default (cannot be changed)
• If we compress the data: the checksum of the original (uncompressed) data is calculated before being compressed and written to the
disk and is stored on disk with the data *
• If the data is not compressed (by user selection or because of incompressibility), the checksum is calculated and stored elsewhere **
• Physical Checksum (protects the compressed data)
• Protects the integrity of the Log itself
• Computed for the Log, after placing Entries into the Log
• Computed over the compressed data and the embedded metadata
• thus protects the integrity of the compressed data
• Metadata Checksum
• Maintaining the integrity of the metadata itself is crucial
• Cannot reconstruct metadata from (compressed) user data
• Disk level metadata
• There is a checksum for each physical row in the metadata that lives on each disk
• If we detect an error in the metadata, we do not trust anything on the disk and trigger a rebuild

Background Device Scanner

Scans devices in the system for errors
• You can enable/disable the Background
Device Scanner & reset its counters
• MG storage pools
• Disabled by default
• No changes, same as 2.x
• FG storage pools
• Enabled by default
• Mode: device_only – report and rebuild on error
• Cycle through each SSD and compare the Physical
Checksums against the data in the Logs and Metadata
• GUI controls/limits disk IO – default is 1024 KB/s per device

Choose the best Layout for each workload
• being able to choose for each workload
the layout that works best for you
• MG
• Workloads with high performance requirements and sensitivity
• All of our usual use cases still apply
• FG compressed
• A great choice for most cases where data is compressible
• And where space efficiency is more valuable than raw IO
• Esp. when there is snapshot usage / requirements
• DevOps and Test/Dev environments
• FG non-compressed
• Data isn’t compressible (e.g. OS or application-level encryption)
• But you use lots of snapshots & want the space savings
• Read-intensive workloads w/ >4K IOs
• Need persistent checksums
• And change your mind… You can migrate “live” to another

on-Disruptive
Volume Migration

Prior to v3.0, a volume is bound to a Storage Pool on creation and this binding cannot be later changed
• There are various use cases:
– Migrating volumes between different performance tiers
– Migrating volumes to a different Storage Pool or Protection Domain driven by multi-tenancy needs
– Extract volumes from a deprecating Storage Pool or Protection Domain to shrink a system
– Change a volume personality
• Thin -> Thick
• FG -> MG
• Migrating volumes from one Storage Pool to another
– V-Tree granularity – volume and all snapshots are migrated together
– Non-disruptive to ongoing IO, hiccups are minimized
– Migration supported across
• Storage Pools within the same Protection Domain
• Storage Pools across Protection Domains
• Supports older v2.x SDCs

Snapshots and Snapshot Policy Management

Volume Snapshots
• Prior to v3.0, there was a limit of 32 items in a volume tree (V-Tree)
– 31 snapshots + root volume
• In v3.0, this is increased to 128 (for both FG and MG layouts)
– 127 snapshots + root volume
• Snapshots in FG are more space efficient and have better performance
– In comparison to MG snapshots
– 4KB block management, 256x less to manage with each subsequent write
• Remove Ancestor snapshot
– Ability to remove the parent of a snapshot and maintain the snapshot in the system
– In essence merging the parent to a child snapshot
• Policy managed snapshots
– Up to 60 policy-managed snapshots per root volume (taken from the 128 total available)

Snapshot Policy
• The policy is hierarchical
• For example, we would like to keep:
– An hourly backup for the most recent day
– A daily backup for a week
– A weekly backup for 4 weeks
• Implementation is simplified – set the basic
cadence, and the number snapshots to
keep at each level
– The number of snapshots to keep is the same as
the rate of elevating the snapshot to the next level
• Max retention levels = 6
• Max snapshots retained in a policy = 60

Auto Snapshot Group
The snapshots of an auto snapshot group

– Consistent (unless mapped)
– Share the same expiration and should be deleted at the same time (unless locked)
Auto Snapshot Group is NOT a Snapshot Consistency Group
– A single snapshot CG may contain several auto snapshot groups
– Snapshot CGs are not aware of locked snapshots
▪ Therefore deleting snapshot CGs which contain auto snapshots is blocked
Auto snapshot is a snapshot which
was created by a policy
The auto snapshot group is an internal
bject not exposed to the user
– Hinted when snapshots are grouped by date/time in several views

Updated System Limits

Maximum SDS capacity has increased from 96TB to 128TB
Maximum SDS per PD has increased from 128 to 256
Maximum snapshot count per source volume is now 128 (FG/MG)
Fine Granularity (FG)
▪ Maximum allowed compression ratio: 10x
▪ Maximum allowed overprovisioning: 10x (compare vs. 5x in MG thin-provisioned)
SDC limitation in vSphere
▪ 6.5 & 6.7 – up to 512 mapped volumes
▪ 6.0 – up to 256 mapped volumes

Updates and Changes

VxFlex OS 3.0
• Added Support for native 4Kn sector drives
– Logical Sector size & physical Sector size fields
• Removed
– Windows backend (SDS,MDM) support
▪ No support for Windows HCI, only compute nodes (SDC)
– AMS Compute feature support
• Security updates:
– Java: Enable newer versions of Java 8 builds
– CentOS 7.5 SVM passed NESSUS security scanning and STIG
• New mapping required to define disk type in a storage pool (SSD/HDD)
– Attempt to add disks that are not of the correct type will be blocked
– Existing SPs will need to be assigned a Media type post upgrade
• Transition to CentOS 7.5 Storage VM
– New 3.0 SVM installations only
– Replace SVM from SLES11.3/12.2 to CentOS 7.5 will be available after 3.0 (3.0.x)

OS Patching
• New Ability in the IM\GW to run a user provided script on a VxFlex OS system as part of an
orchestrated, non-disruptive process (like NDU), which is usually intended for OS patching
• Supported on RHEL and SLES
• Using this feature includes two main steps
User should manually copy the script file to each vxFlex OS host using those prerequisites:
1. Main script name must be patch_script (we check result code is 0 at the end of execution)
2. Verification script name must be verification_script (we check result code is 0 at the end of execution)
3. The script must be copied to ~/lia/bin folder and add execution permissions
• RC codes are saved in the LIA log and an error is returned if needed to the GW
1. User execute the scripts from IM\GW UI
2. It’s the customer responsibility to test the patch_script and verification_scripts prior to running the process via GW

• Execution steps:
1. Login to IM\Gateway web view
2. Select “Maintain Tab”
3. Enter MDM IP & Credentials
4. Under “System Logs & Analysis” select “Run Scrip On Host”

OS Patching
1. Run Script on Host window open
2. Select the scope of running the script/s on
• Entire System – All vxFlex OS Nodes
“In parallel on different Protection Domains” – By default the script is
running on first host’s PD then move to the second and so on. By
selecting this option, the patch_script will run in parallel on all PDs.
• Protection Domain : Specific PD
• Fault set : specific fault set
• SDS : single node
Note: PD’s that don’t have MDM’s will be first , and cluster Nodes will be
last.
3. Define “Running configuration” parameters
• Stop process on script failure
• Script Timeout: How much time to wait for the script to finish
• Verification Script: Do you want to run verification_script after
patch_script was run
• Post script action: Do you want to reboot the host after patch_script
executed.
• If reboot selected – patch_script will run à Reboot à verification_script
will run

• Press “Run script on Hosts”, Validate phase will start
• This phase sends a request to each of the host’s LIA the verify the existence of patch_script and
verification_script (if selected) files under ~/lia/bin
• Press “Start execution phase” button
• IM will make some verifications: check no filed capacity, check spare capacity, check cluster is in valid
state and no other SDS is in maintenance mode.
• Enter SDS to maintenance mode , Run the patch_script
• Reboot host (If required)
• Run verification script (If required)
• Exit from maintenance mode
• Operation completed
• After successful run the patch_script file is deleted and backup file of it created on the same
folder with the name backup_patch_script
OS Patching
Configuration Step III

Multi LDAP Servers Support
• Deploy GW as usual, post Deploy use FOSGWTool tool to add LDAP servers to the GW login
authority
• Support up to 8 LDAP servers
• We use the same method as configuring a single LDAP server to support multiple (change in
command syntax)
• New capability in FOSGWTool, to add multiple LDAP servers
• Details will be available in the LDAP TN
• Log file is the same as Gateway logs (operations.log, scaleio.log and scaleio-trace.log)
• Usual errors are related to syntax of commands or networking misconfiguration

GW Support in LDAP for LIA

• New ability to deploy system with LIA user already configured to use LDAP
• In Deployment you can configure the first LDAP server
• In Query phase the communication to LDAP is performed to validate the info
• So install will not proceed until the LDAP check has passed
• Post upgrade ability to switch LIA from local user to LDAP user
• Ability to Add \ Remove up to 8 LDAP servers
• Check is done during add or Remove, any error will fail the operation.

You can download VxFlex OS v3.0 from the link below (click the screenshot)

And you can download the documentation from here

You can also watch a video below, showing the new compression and snapshots functionalities