EMC with Mirantis Openstack

Editor's Notes

• #3: The changes that are going on in IT with disruptions from technology, business and culture and so IT to solve the issues has to change from moving from traditional models to broker provider model. For this to occur they need to drive to a Hybrid IT model where they can need to adopt a Cloud Framework. Adoption of a hybrid IT model for capability and capacity. Manage risk across the cloud supply chain. Visibility, Governance and control across Clouds.
• #4: OpenStack is an enabler for IT Organizations to build a Private Cloud geared towards a S/W defined model and at same time effectively provide the capability to move towards a Dev-Op model. EMC solutions and service will deliver a service which enables cloud management, right applications and application architectures to run on the Cloud and provide dev-ops advisory services. Lends itself to Applications which uses API to ask for “sets of resources”…OpenStack provides open standard API which can be consumed and OpenStack controller has the capability to schedule the reosource in an optimal way and manage the resources. API lends itself for dev-ops where operators can automate infrastructure pre and post using Puppet/Chef and openstack has good integration with Config Mgmt tools and CI/CD tools.
• #5: Reasons customers are giving for why the want OpenStack (Drive each to agility when natural in the talk track) Operational Efficiency – OpenStack designed for self-service; end-users get to resources more quickly Open Platform – Open source; avoids vendor lock-in and leverages an entire community Choice – large ecosystem of vendors to choose from to deploy OpenStack – hardware/software agnostic Choose your own storage/network etc. Innovate and Compete – more agile; design for Platform 3 – use case changes come from community and can head towards the new; Competes on next generation applications
• #6: Talk about OpenStack how the architecture is modular and flexible – you can pick the service you need Delivers IaaS servie
• #7: Platform 1: Mainframe era with mainframe application workloads Platform 2: Client-Server and virtualized x86 traditional app workloads Platform 3: Application built on NGN architecture for cloud, social, mobile and big data Platform 2: Monolithic Applications Workloads Scale Up Applications Expect Resilient Infrastructure Infrastructure Provides Resiliency High Degree of Virtualization IT Operational Processes Largely Unchanged Platform 2.5: Monolithic Applications Workloads Scale Up Applications Assume Resilient Infrastructure IT Process Automation – Accelerate/Automate IT Processes More Agile IT More Agile DevOps Focus Platform 3 Apps Loosely Coupled, Small Components Stateless Execution Modules Application Takes Responsibility of Resiliency, Fault Tolerant. Assume High Data Resiliency Workloads Easily Scale Out DevOps Focus
• #9: Cluster Mgmt (IT Automation) - Config/package mgmt --- what/how do things get installed Deployment Naming Monitoring How to deal with failures….: planned and unplanned….? Utilization Maintainence Capistrano for deployment… Enterprise Infra Admin Needs: A great management interface for hardware resource utilization, quotas, and good back-ups and a recovery plan. A user friendly administrative GUI interface, and a logically set out and explained command line instruction set. Well documented APIs to integrate into other tools. Cloud Admin: Needs: A great management interface for hardware resource utilization, quotas, and good back-ups and a recovery plan. A user friendly administrative GUI interface, and a logically set out and explained command line instruction set. Well documented APIs to integrate into other tools. Dev-Ops/Developer Needs: A user friendly GUI interface, and a logically set-out and explained command line instruction set. Integration with her preferred CI tool.
• #10: Trove and Sahara Framework…
• #11: Isilon - ADD XtremIO ScaleIO ViPR
• #13: Large service
• #16: Fuel Automated Install Full stack support Robust OpenStack distribution; Best in Class Recognized OpenStack training Best in class storage Wide storage portfolio Cinder Project Leadership Already a big contributor Leverage Community and listen to our customers to Continually improve and innovate EMC Cinder Storage Drivers Become larger contributor
• #19: Fuel is an open source deployment and control plane for OpenStack. Developed as an OpenStack community effort, it provides an intuitive, GUI-driven experience for automated deployment and management of OpenStack, related community projects and plugins.
• #20: Fully automated storage tiering support VNX supports Fully automated storage tiering which requires the FAST license activated on the VNX. The OpenStack administrator can use the extra spec key storagetype:tiering to set the tiering policy of a volume and use the extra spec key fast_support=True to let Block Storage scheduler find a volume back end which manages a VNX with FAST license activated. Here are the five supported values for the extra spec key storagetype:tiering: StartHighThenAuto (Default option) Auto HighestAvailable LowestAvailable NoMovement Tiering policy can not be set for a deduplicated volume. The user can check storage pool properties on VNX to know the tiering policy of a deduplicated volume. Here is an example about how to create a volume with tiering policy: $ cinder type-create "AutoTieringVolume" $ cinder type-key "AutoTieringVolume" set storagetype:tiering=Auto fast_support=True $ cinder type-create "ThinVolumeOnLowestAvaibleTier" $ cinder type-key "CompressedVolumeOnLowestAvaibleTier" set storagetype:provisioning=thin storagetype:tiering=Auto fast_support=True  FAST Cache support VNX has FAST Cache feature which requires the FAST Cache license activated on the VNX. The OpenStack administrator can use the extra spec key fast_cache_enabled to choose whether to create a volume on the volume back end which manages a pool with FAST Cache enabled. The value of the extra spec key fast_cache_enabled is either True or False. When creating a volume, if the key fast_cache_enabled is set to True in the volume type, the volume will be created by a back end which manages a pool with FAST Cache enabled.  Storage group automatic deletion For volume attaching, the driver has a storage group on VNX for each compute node hosting the vm instances that are going to consume VNX Block Storage (using the compute node's hostname as the storage group's name). All the volumes attched to the vm instances in a computer node will be put into the corresponding Storage Group. If destroy_empty_storage_group=True, the driver will remove the empty storage group when its last volume is detached. For data safety, it does not suggest to set the option destroy_empty_storage_group=True unless the VNX is exclusively managed by one Block Storage node because consistent lock_path is required for operation synchronization for this behavior.  EMC storage-assisted volume migration EMC VNX direct driver supports storage-assisted volume migration, when the user starts migrating with cinder migrate --force-host-copy False volume_id host or cinder migrate volume_id host, cinder will try to leverage the VNX's native volume migration functionality. In the following scenarios, VNX native volume migration will not be triggered: Volume migration between back ends with different storage protocol, ex, FC and iSCSI. Volume is being migrated across arrays.  Initiator auto registration If initiator_auto_registration=True, the driver will automatically register iSCSI initiators with all working iSCSI target ports on the VNX array during volume attaching (The driver will skip those initiators that have already been registered). If the user wants to register the initiators with some specific ports on VNX but not register with the other ports, this functionality should be disabled.  Initiator auto deregistration Enabling storage group automatic deletion is the precondition of this functionality. If initiator_auto_deregistration=True is set, the driver will deregister all the iSCSI initiators of the host after its storage group is deleted.  Read-only volumes OpenStack supports read-only volumes. The following command can be used to set a volume to read-only. $ cinder readonly-mode-update volume TrueAfter a volume is marked as read-only, the driver will forward the information when a hypervisor is attaching the volume and the hypervisor will have an implementation-specific way to make sure the volume is not written.  Multiple pools support Normally a storage pool is configured for a Block Storage back end (named as pool-based back end), so that only that storage pool will be used by that Block Storage back end. If storage_vnx_pool_name is not given in the configuration file, the driver will allow user to use the extra spec key storagetype:pool in the volume type to specify the storage pool for volume creation. If storagetype:pool is not specified in the volume type and storage_vnx_pool_name is not found in the configuration file, the driver will randomly choose a pool to create the volume. This kind of Block Storage back end is named as array-based back end. Here is an example about configuration of array-based back end: 1 2 3 4 5 6 7 8 9 san_ip = 10.10.72.41 #Directory path that contains the VNX security file. Make sure the security file is generated first storage_vnx_security_file_dir = /etc/secfile/array1 storage_vnx_authentication_type = global naviseccli_path = /opt/Navisphere/bin/naviseccli default_timeout = 10 volume_driver = cinder.volume.drivers.emc.emc_cli_iscsi.EMCCLIISCSIDriver destroy_empty_storage_group = False volume_backend_name = vnx_41 In this configuration, if the user wants to create a volume on a certain storage pool, a volume type with a extra spec specified the storage pool should be created first, then the user can use this volume type to create the volume. Here is an example about creating the volume type: $ cinder type-create "HighPerf" $ cinder type-key "HighPerf" set storagetype:pool=Pool_02_SASFLASH volume_backend_name=vnx_41Multiple pool support is still an experimental workaround before blueprint pool-aware-cinder-scheduler is introduced. It is NOT recommended to enable this feature since Juno just supports pool-aware-cinder-scheduler. In later driver update, the driver side change which cooperates with pool-aware-cinder-scheduler will be introduced.  Volume number threshold In VNX, there is a limit on the maximum number of pool volumes that can be created in the system. When the limit is reached, no more pool volumes can be created even if there is enough remaining capacity in the storage pool. In other words, if the scheduler dispatches a volume creation request to a back end that has free capacity but reaches the limit, the back end will fail to create the corresponding volume. The default value of the option check_max_pool_luns_threshold is False. When check_max_pool_luns_threshold=True, the pool-based back end will check the limit and will report 0 free capacity to the scheduler if the limit is reached. So the scheduler will be able to skip this kind of pool-based back end that runs out of the pool volume number.  FC SAN auto zoning EMC direct driver supports FC SAN auto zoning when ZoneManager is configured. Set zoning_mode to fabric in back-end configuration section to enable this feature. For ZoneManager configuration, please refer to the section called “Fibre Channel Zone Manager”.  Multi-backend configuration 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 [DEFAULT] enabled_backends = backendA, backendB [backendA] storage_vnx_pool_name = Pool_01_SAS san_ip = 10.10.72.41 #Directory path that contains the VNX security file. Make sure the security file is generated first. storage_vnx_security_file_dir = /etc/secfile/array1 naviseccli_path = /opt/Navisphere/bin/naviseccli #Timeout in Minutes default_timeout = 10 volume_driver = cinder.volume.drivers.emc.emc_cli_fc.EMCCLIFCDriver destroy_empty_storage_group = False initiator_auto_registration = True [backendB] storage_vnx_pool_name = Pool_02_SAS san_ip = 10.10.26.101 san_login = username san_password = password naviseccli_path = /opt/Navisphere/bin/naviseccli #Timeout in Minutes default_timeout = 10 volume_driver = cinder.volume.drivers.emc.emc_cli_fc.EMCCLIFCDriver destroy_empty_storage_group = False initiator_auto_registration = True [database] max_pool_size = 20 max_overflow = 30 For more details on multi-backend, see OpenStack Cloud Administration Guide.  Force delete volumes in storage groups Some available volumes may remain in storage groups on the VNX array due to some OpenStack timeout issues. But the VNX array does not allow the user to delete the volumes which are still in storage groups. The option force_delete_lun_in_storagegroup is introduced to allow the user to delete the available volumes in this tricky situation. When force_delete_lun_in_storagegroup=True is set in the back-end section, the driver will move the volumes out of storage groups and then delete them if the user tries to delete the volumes that remain in storage groups on the VNX array. The default value of force_delete_lun_in_storagegroup is False. Questions? Discuss on ask.openstack.orgFound an error? Report a bug against this page Legal notices
• #21: # A list of backend names to use. These backend names should # be backed by a unique [CONFIG] group with its options (list # value) enabled_backends=vnxiscsi,vnxfc [database] max_pool_size = 20 max_overflow = 30 [vnxiscsi] storage_vnx_pool_name=OpenStack_iSCSI san_ip=192.168.1.30 san_secondary_ip=192.168.1.31 san_login=sysadmin san_password=sysadmin storage_vnx_authentication_type=global volume_driver=cinder.volume.drivers.emc.emc_cli_iscsi.EMCCLIISCSIDriver naviseccli_path=/opt/Navisphere/bin/naviseccli #Timeout in Minutes default_timeout = 10 destroy_empty_storage_group = False initiator_auto_registration = True volume_backend_name=vnx_iscsi [vnxfc] storage_vnx_pool_name=OpenStack_FC san_ip=192.168.1.30 san_secondary_ip=192.168.1.31 san_login=sysadmin san_password=sysadmin storage_vnx_authentication_type=global volume_driver=cinder.volume.drivers.emc.emc_cli_fc.EMCCLIFCDriver naviseccli_path=/opt/Navisphere/bin/naviseccli default_timeout=30 destroy_empty_storage_group=False volume_backend_name=vnx_fc
• #23: All Flash array ideal for High Performance Scale Out Architecture - scale storage resources together with cloud infrastructure Supported Protocols: FC and iSCSI Provide support for main Volume Operations Integrated into OpenStack trunk Setting thin provisioning and multipathing parameters To support thin provisioning and multipathing in the XtremIO Array, the following parameters from the Nova and Cinder configuration files should be modified as follows: Thin Provisioning All XtremIO volumes are thin provisioned. The default value of 20 should be maintained for the max_over_subscription_ratio parameter. The use_cow_images parameter in thenova.conffile should be set to False as follows: use_cow_images = false Multipathing The use_multipath_for_image_xfer parameter in thecinder.conf file should be set to True as follows: use_multipath_for_image_xfer = true [Default] enabled_backends = XtremIO [XtremIO] volume_driver = cinder.volume.drivers.emc.xtremio.XtremIOFibreChannelDriver san_ip = XMS_IP xtremio_cluster_name = Cluster01 san_login = XMS_USER san_password = XMS_PASSWD volume_backend_name = XtremIOAFA
• #24: [DEFAULT] # A list of backend names to use. These backend names should # be backed by a unique [CONFIG] group with its options (list # value) enabled_backends = xioiscsi,xiofc [xioiscsi] san_ip=192.168.50.50 san_login=openstack san_password=Password123! volume_driver=cinder.volume.drivers.emc.xtremio.XtremIOISCSIDriver volume_backend_name=xio_iscsi [xiofc] san_ip=192.168.50.50 san_login=openstack san_password=Password123! volume_driver=cinder.volume.drivers.emc.xtremio.XtremIOFibreChannelDriver volume_backend_name=xio_fc
• #26: Software solution Elastically can scale Data protection – replicates twice…supports erasure coding Cinder driver interfaces between ScaleIO and OpenStack Presents volumes to OpenStack as block devices available for storage ScaleIO driver executes volume operations by communicating with the backend ScaleIO components through the ScaleIO REST Gateway Presentation Layer: ScaleIO Data Client (SDC) Block Device Driver Exposes volumes to applications Service must run to provide access to volumes Over TCP/IP Data Server: ScaleIO Data Server (SDS) Abstracts storage media Contributes to storage pools Performs I/O operations ScaleIO Metadata Manager Not in the data path Monitoring and Configuration Holds cluster wide component mapping
• #31: The OpenStack Block Storage service provides persistent block storage resources that OpenStack Compute instances can consume. This includes secondary attached storage similar to the Amazon Elastic Block Storage (EBS) offering. In addition, you can write images to a Block Storage device for Compute to use as a bootable persistent instance. The Block Storage service differs slightly from the Amazon EBS offering. The Block Storage service does not provide a shared storage solution like NFS. With the Block Storage service, you can attach a device to only one instance. The Block Storage service provides:
• #34: The cinder command-line interface provides the tools for creating a volume backup. You can restore a volume from a backup as long as the backup's associated database information (or backup metadata) is intact in the Block Storage database. Run this command to create a backup of a volume: $ cinder backup-create VOLUMEWhere VOLUME is the name or ID of the volume. This command also returns a backup ID. Use this backup ID when restoring the volume: $ cinder backup-restore BACKUP_ID Alternatively, you can export and save the metadata of selected volume backups. Doing so precludes the need to back up the entire Block Storage database. This is useful if you need only a small subset of volumes to survive a catastrophic database failure. Because volume backups are dependent on the Block Storage database, you must also back up your Block Storage database regularly to ensure data recovery.
• #35: Because volume backups are dependent on the Block Storage database, you must also back up your Block Storage database regularly to ensure data recovery. Export and import backup metadata A volume backup can only be restored on the same Block Storage service. This is because restoring a volume from a backup requires metadata available on the database used by the Block Storage service. NoteFor information about how to back up and restore a volume, see the section called “Back up and restore volumes”. You can, however, export the metadata of a volume backup. To do so, run this command as an OpenStack admin user (presumably, after creating a volume backup): $ cinder backup-export BACKUP_IDWhere BACKUP_ID is the volume backup's ID. This command should return the backup's corresponding database information as encoded string metadata.
• #36: .   https://etherpad.openstack.org/p/juno-cinder-cinder-consistency-groups https://etherpad.openstack.org/p/icehouse-cinder-continuous-volume-replication-v2   Create a number of volumes in Cinder. should create the CG first, and then associate the volume with it at volume create time Can we not just "Create within CG" ? Yes, that could be done as well.  I think that is what is being proposed.  2.     Create a CG, specifying volumes to be added to the CG. And the volume type You can only have one volume type within a CG  3.     Create a snapshot of the CG.  -       Cinder API creates cgsnapshot and individual snapshot entries in the db and sends request to Cinder volume node.  -       Cinder manager calls novaclient which calls a new Nova admin API "quiesce" that uses QEMU guest agent to freeze the guest filesystem. Can leverage this work: https://wiki.openstack.org/wiki/Cinder/QuiescedSnapshotWithQemuGuestAgent  -       Cinder manager calls Cinder driver.  -       Cinder driver communicates with backend array to create a point-in-time consistency snapshot of the CG.  -       Cinder manager calls novaclient which calls a new Nova admin API "unquiesce" that uses QEMU guest agent to thraw the guest filesystem.  Need to think about a tool (nova-manage or cinder-manage or similar) to fix things up if cinder goes down between quiesce and unquiesce Nova will likely be polling for updates and eventually timeout and unfreeze the instance?  4.     Create a backup of the CG.  -       Cinder backup API creates cgbackup and individual backup entries in the db and sends request to Cinder volume node.  -       Cinder backup manager calls novaclient which calls a new Nova admin API "quiesce" that uses QEMU guest agent to freeze the guest filesystem. Can leverage this work: https://wiki.openstack.org/wiki/Cinder/QuiescedSnapshotWithQemuGuestAgent  -       Cinder backup manager calls Cinder driver which calls the backup driver.  -       Cinder backup driver communicates with backup backend (swift, ceph, or other vendor specific backends) to create a point-in-time consistency backup of the CG.  -       Cinder backup manager calls novaclient which calls a new Nova admin API "unquiesce" that uses QEMU guest agent to thraw the guest filesystem.  If a CG is to be modified by adding or removing volumes, we’ll check whether it already has cgsnapshots and cpbackups.  If it does, then the CG cannot be modified.  Currently, a volume can be backed up only when it is available.  For creating backups of a CG, we need to support backups when the volume is attached. This needs driver work, so might come later
• #39: Quotas are operational limits. For example, the number of gigabytes allowed per tenant can be controlled to ensure that a single tenant cannot consume all of the disk space. Quotas are currently enforced at the tenant (or project) level, rather than the user level.
• #41: <a id="d9e5978" class="indexterm">use_syslog=True syslog_log_facility=LOG_LOCAL2</a> Elasticsearch - index and enables search and storage
• #42: Logstash Elasticsearch Kibaba spluk
• #45: Dashboard ("Horizon") provides a web front end to the other OpenStack services Compute ("Nova") stores and retrieves virtual disks ("images") and associated metadata in Image ("Glance") Network ("Quantum") provides virtual networking for Compute. Block Storage ("Cinder") provides storage volumes for Compute. Image ("Glance") can store the actual virtual disk files in the Object Store("Swift") All the services authenticate with Identity ("Keystone")
• #46: Cinder API A WSGI app that authenticates and routes requests throughout the Block Storage service. It supports the OpenStack APIs Cinder Scheduler Schedules and routes requests to the appropriate volume service. Depending upon THE configuration, could be simple round-robin scheduling or it can be more sophisticated through the use of the Filter Scheduler. The Filter Scheduler is the default and enables filters on things like Capacity, Availability Zone, Volume Types, and Custom filters Cinder Volume Manages Block Storage devices, specifically the back-end devices themselves Cinder Backup Provides a means to back up a Block Storage volume to OpenStack Object Storage.
• #47: Think of it as a toolkit to build private clouds.
• #48: 1. The Cinder client, in this case Horizon, makes a request to create a volume on the block storage. 2. The Cinder REST API processes the request and validates it, making sure that the correct credentials are provided. It then places the message into the Cinder Message BUS. 3. The Cinder volume process picks the request from the Message BUS and sends it to the Cinder scheduler to determine which block based storage to provision to based on the capabilities asked for in the request. 4. The Cinder Scheduler now takes the message off of the queue and generates a list of possible storage candidates, based on the capabilities required from the request, such as volume type, sizing etc. 5. The Cinder Volume process reads the response from the Scheduler and looks through the list and invokes the correct storage drivers, for example, in this case the EMC VNX Cinder drivers. 6. The VNX Cinder driver creates the requested storage volume, interacting with the storage sub-systems. For the VNX it will be a direct CLI call. 7. he Cinder Volume driver gets the response back for connection information and puts it into the Message Queue. 8. The Cinder API process reads the response in the queue and responds to client. 9. Finally, the Cinder client (in this case Horizon) gets the response informing of the status for the creation request, ie: volume UUID.