Blog

  • REST API and DellEMC Storage Part 3 – Unity

    REST API and DellEMC Storage Part 3 – Unity

    This blog post is 3rd part of REST API with DellEMC Storage blog series.

    • In the first part of this blog series, we discussed what is REST API and different usage options
    • Second part was about managing DellEMC PowerMax storage arrays using REST API

    In this post, we will discuss how you can use manage DellEMC Unity storage using REST API. We will be using the Postman tool during the entire blog series. So let’s get started with automating the DellEMC Unity storage system.

    The DellEMC Unity REST API Background

    DellEMC Unity is of the most user-friendly storage systems. The most common management tools for Unity systems are

    • Unisphere UI (Embedded) – An HTML5 graphical user interface used to manage Dell EMC Unity systems
    • Unisphere Command Line Interface (UEMCLI) – UEMCLI allows a user to perform tasks on the storage system by typing commands instead of using the graphical user interface

    The Dell EMC Unity includes complete REST API support, providing a developer-friendly way to manage Dell EMC Unity systems and automate various tasks.

    Dell EMC Unity’s REST API fully supports all the management tasks that a user can perform in the Unisphere GUI. Dell EMC Unity’s REST API response formats all communication in JSON notation. Users can send REST API requests using their favorite REST API tools to manage Dell EMC Unity systems in their environment. This provides flexibility in management and opens possibilities for more complex operations.

    DellEMC Unity Management Options

    Assessing DellEMC Unity’s REST API

    Once a Unity system is up and running, users can navigate to the following web addresses to get access to the REST API documentation:

    REST API Programmer’s Guide – https://{{unisphere_management_address}}/apidocs/programmers-guide/index.html

    REST API Reference Guide https://{{unisphere_management_address}}/apidocs/index.html

    DellEMC Unity’s REST API is available via Unisphere running on the array via the following Base URL.

    https://{{unisphere_management_address}}/api

    • {{unisphere_management_address}} – Replace with IP Unisphere IP address or hostname

    Supported DellEMC Unity REST API Operations

    DellEMC Unity’s REST API supports the following types of REST calls.

    • GET – Get information on objects. For example – Get Unity storage system’s details
    • POST – Create an Object. For example – Create new LUN/s
    • PUT – Making changes to an objects. For example – Change size of the existing LUN
    • DELETE – Remove an object. For example – Delete existing LUN/s

    Usually the REST client (like Postman) can be used to help figure out what REST calls you want to run.

    Building your REST API calls

    Now let’s get started with creating REST API calls. In this example we will create sample REST API call to list all the available storage pools.

    Before we get started make sure you’ve Postman installed and Unisphere is reachable.

    • Open Postman and click on New. Under new drop-down, select Request
    DellEMC Unity REST API – Postman tool GUI – 1
    • In New Request pop-up enter Request nameDescription (optional) and Name of the Collection. Then click on Save.
    DellEMC Unity REST API – Postman tool GUI – 2
    • Click on the request type drop-down and select GET.
      • Please note that we are selecting GET because is this example we are creating sample REST API call to list all the available storage pools.
      • This option will be different based on type of REST API operation
    DellEMC Unity REST API – Postman tool GUI – 3
    • Enter below Request URL
      • 1.1.1.1 – Replace with Unisphere IP address/hostname

    https://1.1.1.1/api/types/pool/instances

    DellEMC Unity REST API – Postman tool GUI – 4
    • Click on the Authorization. Enter Unisphere Username and Password.
    DellEMC Unity REST API – Postman tool GUI – 5
    • Note that Unity REST API GET request needs below 3 headers. Click on Headers and enter below header details as shown in the screenshot. Then click Send
      • Accept – application/json
      • Content-type – application/json
      • X-EMC-REST-CLIENT – true
    DellEMC Unity REST API – Postman tool GUI – 5
    • In the Postman Response section you’ll see REST API response. In this case you’ll see list of all the storage pools in Unity array.
    DellEMC Unity REST API – Postman tool GUI – 6

    Additionally please note that POST/PUT/DELETE requests need one additional Header – EMC-CSRF-TOKEN. This token is generated using GET request.

    So, let’s create one POST request for creating new LUN.

    • Follow above-listed GET request steps. Click on Headers under GET Response. Copy the EMC-CSRF-TOKEN from the Headers
    DellEMC Unity REST API – Postman tool GUI – 7
    • Now click on New and Under new drop-down, select Request (screenshot in GET request steps)
    • In New Request pop-up enter Request nameDescription (optional) and Name of the Collection. Then click on Save. (screenshot in GET request steps)
    • Click on the request type drop-down and select POST.
      • Please note that we are selecting POST because is this second example we are creating REST API call to create new LUN.
    • Click on the Authorization. Enter Unisphere Username and Password.
    • Under Params enter below details.
      • Name – Name of the LUN
      • Pool – Storage Pool in which LUN will be created
      • Size – LUN size
    DellEMC Unity REST API – Postman tool GUI – 7
    • Click on Headers and enter below header details as shown in the screenshot. Then click Send
      • Accept – application/json
      • Content-type – application/json
      • X-EMC-REST-CLIENT – true
      • EMC-CSRF-TOKEN – Copied from GET response
    DellEMC Unity REST API – Postman tool GUI – 8

    Dell EMC and REST API – Way Forward

    I hope this clarifies many basics for getting started with REST API and DellEMC Unity storage. You might also have understood that creating creating valid URLs is very important aspect of using REST API. Having this in mind we have created ready Postman collection for DellEMC Unity storage. Here’s the GitHub link to the repository. Feel free to download and share.

    Below are the additional resources available for taking REST API usage to next level.

    I hope this post will get you started with your Dell EMC Unity automation journey.

  • REST API and DellEMC Storage Part 2 – PowerMax

    REST API and DellEMC Storage Part 2 – PowerMax

    This blog post is 2nd part of REST API with DellEMC Storage blog series. In the first part of this blog series, we discussed what is REST API and different usage options. I highly encourage you to go through the first part before you get started with this post.

    In this post, we will discuss how you can use manage DellEMC PowerMax storage using REST API. We will be using the Postman tool during the entire blog series. So let’s get started with automating the DellEMC PowerMax storage system.

    The PowerMax REST API Background

    There are many different ways to manage the PowerMax storage system. You can refer to this link for more details around each. Traditionally many customers using the VMAX family systems are using the Solutions Enabler tool. This is a comprehensive tool that allows storage administrators to automate many different storage tasks using scripting (Bash, Perl, Shell scripts, etc.).

    PowerMax Unisphere GUI is HTML5 based management interface, it’s beautiful and functional and provides a web-based interactive experience for users.  Unisphere has a lot of automation baked in, and it’s intuitive wizards eliminate complexity and can often provide the right amount of automation for organizations where there isn’t a lot of change. With Unisphere version 8 everything you can do in the GUI is supported using REST API.

    DellEMC PowerMax Management Options

    Assessing DellEMC PowerMax REST API

    DellEMC PowerMax’s REST API is available via Unisphere (installed or embedded) running on the array via the following Base URL.

    https://{{unisphere_management_address}}:{{8443}}/univmax/restapi/{{version}}

    • {{unisphere_management_address}} – Replace with IP Unisphere IP address or hostname
    • {{8443}} – Default port of Unisphere. Change this as per your environment
    • {{version}} – Replace this with Unisphere version. For Unisphere version 9, replace as 90

    Supported DellEMC PowerMax REST API Operations

    Unisphere for PowerMax’s REST API supports the following types of REST calls.

    • GET – Get information on objects. For example – list all the PowerMax serial numbers managed using Unisphere
    • POST – Create an Object. For example – Create new LUN/s
    • PUT – Making changes to an objects. For example – Change size of the existing LUN
    • DELETE – Remove an object. For example – Delete existing LUN/s

    Usually the REST client (like Postman) can be used to help figure out what REST calls you want to run.

    Building your REST API calls

    Now let’s get started with creating REST API calls. In this example we will create sample REST API call to list all the available SRPs.

    Before we get started make sure you’ve Postman installed and Unisphere is reachable.

    • Open Postman and click on New. Under new drop-down, select Request
    DellEMC PowerMax REST API – Postman tool GUI – 1
    • In New Request pop-up enter Request name, Description (optional) and Name of the Collection. Then click on Save.
    DellEMC PowerMax REST API – Postman tool GUI – 2
    • Click on the request type drop-down and select GET.
      • Please note that we are selecting GET because is this example we are creating sample REST API call to list all the available SRPs.
      • This option will be different based on type of REST API operation
    DellEMC PowerMax REST API – Postman tool GUI – 3
    • Enter below Request URL
      • 1.1.1.1 – Replace with Unisphere IP address/hostname
      • 000123456789 – Replace with Serial number of PowerMax array

    https://1.1.1.1:8443/univmax/restapi/90/sloprovisioning/symmetrix/000123456789/srp

    DellEMC PowerMax REST API – Postman tool GUI – 4
    • Click on the Authorization. Enter Unisphere Username and Password. Then click Send
    DellEMC PowerMax REST API – Postman tool GUI – 5
    • In the Postman Response section you’ll see REST API response. In this case you’ll see list of all the SRPs in PowerMax array.
    DellEMC PowerMax REST API – Postman tool GUI – 6

    Dell EMC and REST API – Way Forward

    I hope this clarifies many basics for getting started with REST API and DellEMC storage. You might also have understood that creating creating valid URLs is very important aspect of using REST API. Having this in mind we have created ready Postman collection for DellEMC PowerMax storage. Here’s the GitHub link to the repository. Feel free to download and share.

    Below are the additional resources available for taking REST API usage to next level.

    1. REST API client for Unisphere – This is simple GUI tool which allows you to to construct REST API calls. Best part of this tool is having a tree view of all resources on the Unisphere to which the users can navigate through to select the desired REST call.
    2. DellEMC PowerMax REST API Concepts and Programmer’s Guide – This link has REST API document for Dell EMC PowerMax array.

    I hope this post will get you started with your Dell EMC PowerMax automation journey.

    Follow my blog with Bloglovin

  • Database Performance Benchmark using HammerDB

    Database Performance Benchmark using HammerDB

    I have been using HammerDB for database performance bench-marking . This is very useful tool if you’re getting into any proof of concepts (POC) or testing of new database infrastructure stack before production roll-out.

    In this blog post we will discuss around using HammerDB to generate OLTP (TPC-C workload) on Microsoft SQL database. In my example I had Microsoft SQL and HammerDB server created on AWS EC2 instances. But from HammerDB perspective it doesn’t matter as far as it can communicate to database instance.

    We will follow 5 simple steps to run synthetic workload on MS SQL database. So let’s get started.

    Step 1 – Installing the HammerDB Application

    Before you get started make sure that –

    • HammerDB and MS SQL server are on same network/VLAN
    • MS SQL server is installed and running
    • Login to MS SQL console and create new SQL database. Make sure that new database is created on the target storage disks. If you create database in C drive, then you might not get expected performance due to disk bottleneck.
    Microsoft SQL database console
    • Download HammerDB installer (Click image below)
    HammerDB download link
    • Once HammerDB installer is downloaded, go ahead and install the same. Below are the links for installation steps.

    At this point you should have

    • MS SQL server ready with test database created on desired target storage disks
    • HammerDB installed and running

    Step 2 – Configuration of Schema Build

    We will need to created OLTP workload schema as per TPC-C specifications. Follow below steps for building OLTP schema on target database

    • Open the HammerDB console
    HammerDB – Console
    • Under Benchmark navigation page, double-click on SQL Server. In Benchmark Options pop-up window select SQL Server and TPC-C options. Then click Ok. Click Ok once again to confirm the selection.
    HammerDB – Selecting SQL database and TPC-C workload
    • Under Benchmark navigation now you can see SQL Server selected with TPC-C options.
    HammerDB – SQL server and TPC-C benchmark
    • Expand TPC-C under SQL Server and then expand Schema Build
    HammerDB – TPC-C Schema Build
    • Double-click on Options under Schema Build. Pop-up window of TPC-C Build Options will open. In this window enter below details, and then click Ok
      • SQL Server – IP address or hostname of SQL server. Keep (local) if HammerDB is installed on the SQL server.
      • Authentication – Use Windows Authentication if you want logged-in user credentials to be used for SQL server, else select SQL authentication and enter credentials.
      • SQL Server Database – Name of the database which we had created in Step 1
      • Number of Warehouses – Enter the value to number of warehouses you have chosen for your testing. Preferably select number of warehouses equal to number of cores on the server
      • Virtual Users to Build Schema – Set this value equal to number of warehouses.
    HammerDB – TPC-C Build Options
    • In the Benchmark pane double-click on Build
    HammerDB – TPC-C Schema Build
    • Click Yes to confirm creating schema in the target SQL database.
    • HammerDB will now start creating virtual user threads and create schema in the target database. This process takes some time. You can monitor the status in top-right corner of HammerDB console. (TPC-C creation in top-right)
    HammerDB – TPC-C Schema Creation in process
    • Once completed you can see that the status is changed to Complete
    HammerDB – TPC-C Schema Creation Completed

    Step 3 – Configure Driver Script

    Follow below steps to configure HammerDB driver script

    • Expand the Driver Script from Benchmark navigation pane and double-click on Options
    HammerDB – Driver Script
    • In the TPC-C Driver Options pop-up window enter below details, and then click Ok
      • SQL Server – Keep it same as Step 2
      • Authentication – Keep it same as Step 2
      • Total Transactions Per User – Keep default value. This value will set the number of transactions each virtual user will process before logging off
      • TPC-C Driver Script – Keep this option as Timed Driver Script. This will run the workload for finite time as specified in Minutes for Test Duration
      • Minutes of Rampup Time – The rampup time defines the time in minutes for the monitoring virtual user to wait for the virtual users running the workload to connect to the database. 2 minutes in my case. You can increase this number if you’ve higher number of virtual users.
      • Minutes for Test Duration – The Minutes for Test Duration is shown as duration in the Driver Script. This does not include rampup time.
      • Use All Warehouses – Keep this option checked.
    HammerDB – Driver Script Options
    • In the Benchmark navigation double-click on Load (under Driver Script). You need to Load the Driver Script every time you make changes to Driver Script Options.
    HammerDB – Driver Script Load

    Step 4 – Create Virtual User

    Once HammerDB driver script is loaded, follow below steps to create virtual user.

    • Expand Virtual User from Benchmark pane
    HammerDB – Virtual User
    • Double-click on Options. In the pop-up window enter below details, and then click Ok.
      • Virtual Users – Keep number of users same as Step 2
      • Keep Other inputs as default
    HammerDB – Virtual User Options
    • In the Benchmark navigation pane double-click on Create under Virtual User. This will create virtual users and keep them idle.
    HammerDB – Virtual User Create

    At this point we are ready to start OLTP workload on target database.

    Step 5 – Run HammerDB OLTP (TPC-C) Workload

    Follow below steps to run the OLTP workload and monitor the TPMs.

    • In Benchmark pane double-click on Run (Under Virtual User).
    HammerDB – Run OLTP (TPC-C) workload
    • Now Virtual Users will start logging into the target database and begin running their workload. You can monitor the status under Virtual User 1-MONITOR
    HammerDB – Starting OLTP (TPC-C) Workload – In Progress
    • While workload is running you can monitor the real-time TPM (Transactions Per Minute) by clicking on Transaction Counter
    HammerDB – Transaction Counter
    • Once workload is completed you can see the status in top-right corner as well as under Virtual User 1-MONITOR
    HammerDB – Starting OLTP (TPC-C) Workload – Completed
    • Once the workload is completed note down TEST RESULT under Virtual User 1-MONITOR
    HammerDB – OLTP (TPC-C) TEST RESULT

    You can run multiple tests and take average across them for realistic performance numbers.

    Apart from MS SQL (used in this blog post) HammerDB supports running OLTP (TPC-C) and OLAP (TPC-H) on Oracle, IBM DB2, MySQL, PostgreSQL, MariaDB and Redis.

    I hope this helps everyone.

  • Best Practices For Running Oracle Database On XtremIO X2

    Summary

    DEllEMC’s XtremIO has simple, easy-to-use management. The XtremIO Management Server (XMS) delivers an HTML5 user interface that is a simple and easy-to-use interface for storage administrators. XMS allows storage administrators the ability to provisions storage with very little setup and planning.

    Hope this post is helpful to all Oracle users trying to get best out of their XtremIO investments.

    XtremIO is designed and optimized for databases and for DBAs, providing the following benefits.

    Predictable Performance

    • XtremIO provides predictable and consistency low-latency performance
    • With XtremIO scale-up and scale-out architecture, year-to-year growth is easy. The initial investment is preserved and application performance is improved.
    • Performance is predictable and provides best response times regardless of the workload and environment – be it production, QA, test or development

    Incredible Simplicity

    Agility

    • The typical enterprise applications require multiple copies such as test/development, reporting or online analytics. DBAs and test/dev engineers often have to spend hours managing the DB creation and refreshing the environments while often being limited by capacity, performance, and the number of copies.
    • XtremIO’s Integrated Copy Data Management (iCDM) allows for instant XtremIO Virtual Copies (XVCs) to be created from production with no performance impact.
    • These copies can be repurposed for near real-time analytics, test/dev and any other use case- all with complete space efficiency.

    Protection

    • Protecting the database is easy with XtremIO
    • There is no need for any design covering RAID type, data file capacity, load balancing, and tuning.
    • The data is protected with a proprietary flash-optimized algorithm called XtremIO Data Protection (XDP).
    • XDP is very different from RAID in several ways. Since XDP is always working within an all-flash storage array, several criteria were important in the design of this protection scheme. XDP benefits include ultra-low capacity overhead, high levels of data protection in case of double SSD failure, rapid rebuild times, flash endurance, and of course extreme performance
    • With XtremIO virtual copies it is easy to protect and recover from any operational and logical corruption; XVC’s allow the creation of frequent point-in-time copies (according to RPO intervals – seconds, minutes, hours) and use them to recover from any data corruption
    • An XVC can be kept in the system for as long as needed. Recovery using XtremIO virtual copy is instantaneous and does not impact system performance.

    ORACLE BEST PRACTICES

    1. General Guidelines

    Irrespective of using any application/database with XtremIO storage array below listed general guidelines are common.

    • Keep consistent, duplex link speed on all paths between the host and the XtremIO cluster
    • To ensure continuous access to XtremIO storage during a cluster software upgrade, verify that minimum I/O timeout of 30 seconds is set on the HBAs of all hosts connected to the affected XtremIO cluster. Also, verify that a minimum timeout of 30 seconds is set for all applications that are using storage from the XtremIO cluster.
    • The HBA queue depth (also referred to as execution throttle) controls the amount of outstanding I/O requests per HBA port. The HBA queue depth should be set to the maximum value
    • The LUN queue depth controls the amount of outstanding I/O requests per single path. These settings are controlled in the driver module for the card at the OS level. When connecting Linux host to XtremIO, a LUN queue depth setting should retain its default values.
    • I/O scheduling controls how I/O operations are submitted to storage. Linux offers various I/O algorithms (also known as “I/O Elevators“) to accommodate the different workloads. When connecting a Linux host to XtremIO storage, set the I/O elevator to either noop or deadline. It is not recommended to use the cfq I/O elevator setting, as it’s less optimal for XtremIO storage.
    • It is HIGHLY RECOMMENDED to follow the latest “XtremIO Host Configuration Guide” for all operating system which will use storage from XtremIO
    • If DB is virtualized then make sure all Virtual Machine components are provisioned from XtremIO storage (OS, Application/Binary, Swap, Paging, etc.)

    2. Oracle ASM

    Oracle Automatic Storage Management (ASM) is Oracle’s recommended software for supporting Oracle database files.

    For more information on ASM please refer this link

    • ASM General Recommendation
      • External redundancy is recommended for XtremIO
      • The XtremIO Storage Array natively provides flash-optimized data protection
    • Database Files Location in ASM Disk Groups
      • Best practices for storing Oracle DBMS file types in ASM disk groups are mentioned as below.
    Oracle Database Files Location in ASM disk groups

    Note: The second REDO data group (DG) is applicable if REDO logs are multiplexed.


    • Number of LUNs per Disk Group
      • Excellent cluster performance is achieved using an XtremIO Storage Array with just single LUN in a single disk group. However, in order to maximize performance from a single host, parallelism and adequate utilization of device queues are required.
      • The best practice to achieve this is by using a minimum of four LUNs for the data disk group. Doing this enables the hosts to use parallelism and ensures optimal performance without any bottlenecks.
      • The best practices for Disk group configuration and data placement are outlined in the below table.
    Number of LUNs per disk group
    •  512 verses 4K Advanced Format Considerations
      • The default setting for XtremIO volumes is 512 bytes. It is recommended to keep the default setting and not use 4K Advanced Format.

    3. Multiblock I/O Request Sizes

    Oracle Database performs I/O on data files in multiples of the database block size (db_block_size), which by default is 8KB. The default Oracle Database block size is optimal on XtremIO. XtremIO supports larger block sizes as well. In the case of multiblock I/O one should tune the Oracle Database initialization parameter db_file_multiblock_read_count to limit the requests to 128KB. This is derived with the following formula:

    db_file_multiblock_read_count is db_file_multiblock_read_count = 128KB / db_block_size
    

    Usually, Oracle DB is optimized to perform very large transfers to mitigate the seek cost due to multiblock reads on mechanical/spinning drives. In a seek-free storage environment, such as XtremIO, there is no need for such mitigation. Also, most modern FC HBAs require OS to segment large requests into multiple requests. For example, an application IO of 1MB is fragmented by Linux block I/O layer into two 512KB transfers to suit HBA max transfer size.

    4. REDO Log Block Size

    The default block size for REDO LOG is 512 bytes. I/O requests sent to the redo log files are in increments of the redo block size. This is the blocking factor Oracle uses within REDO LOG files and has nothing to do with the on-disk format of the XtremIO LUN.

    XtremIO’s recommendation is to create REDO LOG files with 4K block size. For more details on this please check Oracle Support notes 1681266.1.


    Note: For Oracle version prior to 12.2.0.1.0, you should set the parameter _disk_sector_size_override to TRUE when creating a redo log with 4K block size in the database instance.

    Do not set the parameter _disk_sector_size_override in the ASM instance. Once the instance is running, simply add more redo logs with the BLOCKSIZE option set to 4KB and then drop any redo logs that have default 512B block size.


    5. Grid Infrastructure Files – OCR/Voting

    The block size for both Oracle Cluster Registry (OCR) and Cluster Synchronization Services (CSS) voting files are 512 bytes, hence I/O is therefore sized as multiple of 512 bytes. This is consistent with XtremIO’s best practices and hence no changes are needed in OCR/Voting files.

    6. Oracle DB Level Compression & Encryption

    XtremIO has inline data reduction (deduplication and compression) running all the time without the performance penalty and stores 100% of data in encrypted format using Data At Rest Encryption (D@RE). This makes Oracle DB level compression and encryption as redundant.

    XtremIO data services work for all the data stored on arrays, unlike being selective like Oracle. Also XtremIO no not use host CPU for data services, which is an expensive resource in the Oracle environment.

    With XtremIO it is a best practice to disable / not use application-level Compression and Encryption services.

    XtremIO Advanced Services for Oracle

    XtremIO offers a wide variety of use cases to simplify database environment workflow. XtremIO comes along with a tool called iCDM (Integrated Copy Data Management) which allows automating all Copy Data Management (CDM) tasks in DB environments.

    Few use cases are mentioned below.

    1. Modern Backup-to-Disk using XtremIO XVC

    XtremIO XVCs (XtremIO Virtual Copy) are precise point-in-time copies of source volumes which basically are a collection of metadata pointers to the source volume blocks. Therefore, XVC consumes minimal physical capacity.

    Executing XVCs is extremely fast and hence most efficient backup-to-disk methodology. The best part is this process does not utilize production/source server resources for creating backup-to-disk copy. Over time as source data is updated/changed, only unique data is stored on XtremIO in compressed format.

    2. XtremIO XVC for Manual Continuous Data Protection (CDP)

    XtremIO XVCs are so efficient that these can be used as part of a business continuity strategy. Below mentioned two options can be used for this.

    • Crash-Consistent (or “Restart-able” Image)
      • A crash-consistent or restartable image is a point-in-time image of the primary database on disk
      • This option involves taking XVC of the primary database while it is up and operational. The image that is captured is similar to the state of the primary database.
      • During the DB restart on the XVC, the DB automatically performs a recovery using the online logs.
      • All committed transactions are included and all uncommitted transactions are rolled back.
    • Application/DB-Consistent (“Recoverable” Image) –
      • A recoverable image is a point-in-time image of the primary database on disk
      • This option involves taking XVC of the primary DB while DB is in “Backup” mode
      • Highly recommended to have a backup file of the control file prior and after the completion of the XVC process.Unlike crash-consistent copy, data files can be rolled forward in time using logs – up to latest or desired SCN (captured in the control file)

    3. XtremIO XVC for Cloning Primary Database (BCV Copy)

    BCV / clones of the primary copies can be created using XtremIO XVCs. Methods for clone creation are as mentioned in “2. XtremIO XVC for Manual Continuous Data Protection (CDP)”

    operating System Best Practices

    When it comes to performance optimization operating system settings also play a major role. It is highly recommended to follow all the operating system best practices as listed in the “XtremIO Host Configuration Guide”.

    The absence of host best practices might result in host-bound performance than XtremIO bound performance. In short, the host/operating system might become the bottleneck, because of the host/operating system level queuing.

  • Microsoft SQL DWH using DellEMC iCDM

    Recently I got engaged with one of our customer who was trying to implement data warehouse using the Microsoft SQL 2017. But they were not able to implement the same into the production environment even after successful POC and testing. When we got engaged with customer DBA teams we used DellEMC’s iCDM functionality (with XtremIO X2 system) in some unique way to help them not just solve their problem but exceeding business SLA expectations. This blog covers the details around problem and solution along with learning.

    Problem Statement

    Customer has several mission-critical MS SQL 2016 databases which are running in 24×7 operation. These databases are supporting their business critical OLTP application.

    Customer’s planned DWH approach

    Business teams were pushing application and DBA teams to create singular reporting platform which will create reporting on data from multiple MSSQL source databases.

    For this project DBA teams built MS SQL 2017 platform which will consolidate data from 3 source MS SQL databases. They created the test setup for feature testing before production roll-out, which worked as per their expectations. But when they implemented this feature in production DBA team realized that this is generating massive load on their source databases and causing performance issues for their business applications, which was completely unacceptable to business teams.

    This forced DBA teams to stop fetching data from the network and restore the data from last backup instead. This was used as workaround because this meant that data in reporting server was more than 30 hours old, which was making reporting irrelevant.

    DellEMC Solution

    When DellEMC team got involved we started with collecting DB environment data collection and business expectation understanding. Once we understood the pain points and business requirement we mentioned to DBAs that traditional way of data management techniques won’t help them. We also mentioned that since they are exiting DellEMC customer they already have the solution with them, which they never implemented.

    Every DellEMC All Flash storage solutions includes bundled copy data management software called Appsync.

    On high level AppSync allows application and database administrators to create application workflows. These workflows allows them to create on demand or scheduled protection or re-purpose copies of databases. We also mentioned that using this software you can create your copies of source MS SQL 2016 DB copies and mount it to target MS SQL 2017 DB server, scheduled or on-demand. These workflows are based on DellEMC storage in back-end and hence can be executed during even the busiest times.

    As usual customer DBA teams didn’t believe us and that’s where it comes to next section of this blog – Demonstration! 🙂

    Demonstration of the Appsync

    To demonstrate the functionality of DellEMC iCDM we installed the Appsync server on of the Windows server VM in customer environment. Below is the high level architecture

    DellEMC’s proposed solution approach for DWH project

    Once Appsync was installed we configured the same to communicate with source and target SQL servers and also DellEMC XtremIO storage. This allows Appsync to discover running databases and create the end to end database mapping.

    Post initial configuration we created the SQL re-purpose copy schedule to create the MS SQL database copy every 6 hours. This schedule was then applied to all the 3 source databases.

    Once the copy of multiple source database was created we used Appsync to mount the same into target MSSQL 2017 server. In our testing we mounted 3 source copies on single target MSSQL 2017 instance. Entire mounting operation completed within couple of minutes. This process allowed customer to save multiple days and help achieve business SLA.

    Apart from solving their most critical problem in hand this solution helped them solve couple of major production issues

    • Database RPO – We reduced production DB RPO to 2 hours instead of 30+ hours
    • Agent-free backup – iCDM helped customer to mount DB production copy on off-host backup server. This helped them completely eliminate backup load from production server.

    If you’re facing similar challenges in your DB environment then highly recommended to use iCDM approach instead of traditional methods.

    I have created another blog post to elaborate more on iCDM and advantages of the same. You can go through the same using below link.

    Databases and Integrated Copy Data Management (iCDM) with DellEMC

    Below are few reference documents for further reading on iCDM

    Dell EMC AppSync Datasheet

    Best Practices for running SQL Server on DellEMC XtremIO X2

  • REST API and DellEMC Storage Part 1 – Introduction

    REST API and DellEMC Storage Part 1 – Introduction

    This post is the first post of multi-part blog series to understand and use RestAPI with DellEMC XtremIO storage.

    REST API with Dell EMC

    REST stands for Representational State Transfer. REST provides access to resources (DellEMC XtremIO resources in our case) on a tree-like structure. REST uses HTTP/S for communication and replies on HTTP’s CRUD operations, which are GET, POST, PUT, DELETE. REST is stateless, which means it does not store application state information. Since REST is stateless client responses are self-documenting. For this introduction post we will talk about XtremIO, but note that each storage system has different URNs.

    REST enables each XtremIO resource (like volumes, initiator groups, etc) having its own URI (Uniform Resource Identifier). Typically REST response is received in JSON or XML format. In the case of XtremIO responses are in JSON format.

    XtremIO REST API can be accessed using the below option

    • REST Clients – Like Postman
    • CLI – Using tools like CURL
    • Programming – Using Python, Ruby, etc.

    Since XtremIO storage array is having API-first design, it allows all the operations using REST which can be done using CLI/GUI.

    Connecting to XtremIO using REST API

    XtremIO is a scale-out storage architecture and has out-of-band management server – aka XMS. You can refer to below high level diagram to check your connectivity.

    DellEMC XtremIO REST API – High Level Connectivity

    Below are the supported types of REST API with XtremIO.

    XtremIO – Supported REST API commands

    Below is the example and details of using XtremIO REST API using CURL

    # curl -k --request GET https://<user>:<pass>@1.1.1.1/api/json/v2/types
    
    • -k – Allow insecure SSL connection. This is needed in case you’ve self-signed certificate.
    • –request GET – This is the REST API request type.
    • https://:@1.1.1.1/api/json/v2/types – URI
      • https:// – Protocol used for REST API
      • <user>:<pass> – XtremIO XMS credentials
      • @1.1.1.1 – XtremIO XMS IP address
      • /api/json/v2/types – API Path

    In next post we will discuss on using REST API with Dell EMC storage systems

  • Ansible with DellEMC Storage: Part 4 – DellEMC PowerMax Ansible Modules

    Ansible with DellEMC Storage: Part 4 – DellEMC PowerMax Ansible Modules

    This blog is the continuation of Ansible with DellEMC storage multi-part blog. 

    • In Part 1 of this series, we discussed getting started with the installation of dependencies for the Ansible and DellEMC Ansible module, followed by Ansible installation.
    • Part 2 was about the high-level basics of Ansible to get you started quickly.
    • Part 3 was getting you through the DellEMC PowerMax Ansible module installation.

    In this 4th part, we will discuss available Ansible modules for DellEMC
    PowerMax storage. Note that this blog is based on DellEMC PowerMax Ansible Module version 1.1 (Released in Dec 2019).

    Before you get started with automating DellEMC PowerMax make sure that you’re running below software versions

    • Software Version – 5978.221.221 / 5978.444.444
    • Unisphere version –  9.0 / 9.1

    Below depicted are the available Ansible modules for DellEMC PowerMax version 1.1.

    DellEMC PowerMax Ansible Module v1.1 – List of available modules

    Before you get started it’s important to understand the purpose of each module. Some of the modules can be data disruptive. You can get more details on each function on this link.

    On a high level, you can refer to the below architecture diagram of Symmetrix family storage provisioning (applicable to PowerMax as well). This will give you heads up on different definitions and object names used in DellEMC PowerMax.

    DellEMC Symmetrix Family – Storage Provisioning

    Assuming now we have an understanding of PowerMax definitions, let’s get started on creating Ansible playbook.

    Note that the default behavior of Ansible is to use SSH for executing tasks on managed hosts, for which we make hosts file entry. Below is the example of specifying host in the hosts file.

    - hosts: webserver
    

    But DellEMC PowerMax Ansible module wraps the RestAPI commands of an array, hence hosts entry isn’t needed. When creating Ansible playbooks for DellEMC PowerMax we’ll need to create the playbook like the below example.

    - hosts: localhost
      connection: local
      gather_facts: no
    

    Now let’s talk about how to create playbook. Below is the simple ansible playbook to create storage group.

    ---
    - hosts: localhost
      connection: local
      gather_facts: no
    
      tasks:
        - name: Create Storage Group using Ansible
          dellemc_powermax_storagegroup:
            serial_no: "000111111333"
            unispherehost: "1.1.1.1"
            universion: "90"
            verifycert: false
            user: "pm_username"
            password: "my_password"
            sg_name: "mySG"
            state: 'present'
    

    Let’s understand tasks parameters used in above sample playbook

    • dellemc_powermax_storagegroup – ansible module used for creating storage group
    • serial_no – Serial number of PowerMax array. Replace this with your array serial
    • unispherehost – IP or hostname of PowerMax Unisphere management. Replace this with your array’s IP/hostname
    • universion – Unisphere version
    • verifiycert – Unisphere might be running on self signed certificate. You can ask ansible to ignore the certificate verification (value = false).
    • user – Unisphere username
    • password – Password for supplied username
    • sg_name – Name of the Storage Group you want to create

    Last 2 lines is where all the magic happens. Here we are asking ansible to create new SG named “mySG”.

    Note that though we have supplied credentials and PowerMax array details in the same playbook, it’s not mandatory. You can always move the variables in the separate file and using Ansible vault to make playbooks reusable (more on this in another blog).

    I hope this helps everyone to get started with automation of DellEMC PowerMax Day 1/2 tasks using Ansible. We will discuss on more sample playbooks in next blog post.

  • Ansible with DellEMC Storage: Part 3 – Installing DellEMC PowerMax Ansible Module

    Ansible with DellEMC Storage: Part 3 – Installing DellEMC PowerMax Ansible Module

    This blog is the continuation of Ansible with DellEMC storage multi-part blog. 

    In Part 1 of this series, we discussed getting started with the installation of dependencies for the Ansible and DellEMC Ansible module, followed by Ansible installation.

    In Part 2 we discussed the high-level basics of Ansible to get you started quickly.

    The purpose of earlier blogs was to get you to familiarize yourself with Ansible. In this blog, we will talk about DellEMC PowerMax Ansible module.

    First let’s get our management server ready. Make sure following pre-requisites are in place

    • PowerMax is running with Unisphere 9.0
    • Red Hat Enterprise Linux 7.5 (or equivalent). CentOS in my case
    • Ansible is installed (min version 2.6)
    • Python 2.7.12 or higher is installed
    • Python library for Unisphere (PyU4V) 3.0.0.14 is installed

    Ansible relies on Python and the Ansible for PowerMax modules rely on the PyU4V Python library. Check this link for more details on the latest PyU4V module.

    Make sure that Python and “pip” are installed. pip is a Python package manager. Install “pip” if required and then use it to install PyU4V.

    Below commands will get pip and PyU4V installed.

    # python -V
    # pip -V
    # yum install python-pip
    # pip install PyU4V
    

    Once the system is ready with required packages next step is to get the PowerMax module from GitHub. To get the modules run below commands.

    # git clone https://github.com/dell/ansible-powermax
    # cd dellemc_ansible
    # ls
    

    This folder (dellemc_ansible) contains multiple documents including “Product Guide” and “Release Notes” for the downloaded version.

    We also need to copy a few files from downloaded modules to Ansible directories. Follow below process to complete the copy operation

    # cp utils/* /usr/lib/python2.7/site-packages/ansible/module_utils/
    # mkdir /usr/lib/python2.7/site-packages/ansible/modules/storage/dellemc/
    # cd /powermax/library
    # ls
    # cp * /usr/lib/python2.7/site-packages/ansible/modules/storage/dellemc/
    

    You’ll get an error in case of dellemc directory already exists, which you can ignore.

    At this point, we are ready with an Ansible server with DellEMC PowerMax modules installed.

    There are multiple files in the downloaded directory, each for different management tasks of DellEMC PowerMax (SRP, Volumes, Masking, etc.). We’ll discuss each module in the next blog post in this series.

  • Linux – Creating Local RAID5 using fdisk

    This blogs lists the steps around creating RAID5 volume on Linux using local disks.

    We will start by installing software RAID on Linux system

    # yum install mdadm
    Loaded plugins: ulninfo
    Resolving Dependencies
    --> Running transaction check
    ---> Package mdadm.x86_64 0:4.1-1.0.1.el7 will be installed
    --> Processing Dependency: libreport-filesystem for package: mdadm-4.1-1.0.1.el7.x86_64
    --> Running transaction check
    ---> Package libreport-filesystem.x86_64 0:2.1.11-43.0.1.el7 will be installed
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    ================================================================================
     Package                  Arch       Version               Repository      Size
    ================================================================================
    Installing:
     mdadm                    x86_64     4.1-1.0.1.el7         ol7_latest     435 k
    Installing for dependencies:
     libreport-filesystem     x86_64     2.1.11-43.0.1.el7     ol7_latest      40 k
    
    Transaction Summary
    ================================================================================
    Install  1 Package (+1 Dependent package)
    
    Total download size: 475 k
    Installed size: 1.0 M
    Is this ok [y/d/N]: y
    Downloading packages:
    (1/2): libreport-filesystem-2.1.11-43.0.1.el7.x86_64.rpm   |  40 kB   00:00
    (2/2): mdadm-4.1-1.0.1.el7.x86_64.rpm                      | 435 kB   00:00
    --------------------------------------------------------------------------------
    Total                                              1.8 MB/s | 475 kB  00:00
    Running transaction check
    Running transaction test
    Transaction test succeeded
    Running transaction
      Installing : libreport-filesystem-2.1.11-43.0.1.el7.x86_64                1/2
      Installing : mdadm-4.1-1.0.1.el7.x86_64                                   2/2
      Verifying  : mdadm-4.1-1.0.1.el7.x86_64                                   1/2
      Verifying  : libreport-filesystem-2.1.11-43.0.1.el7.x86_64                2/2
    
    Installed:
      mdadm.x86_64 0:4.1-1.0.1.el7
    
    Dependency Installed:
      libreport-filesystem.x86_64 0:2.1.11-43.0.1.el7
    
    Complete!
    

    Now let’s identify disks which we will use for creating RAID5 volume. These disks can be local or storage LUNs. You can list the disks using running below command. In this example we will use 5 local disks – /dev/xvd(b-f)

    # fdisk -l | grep /dev/
    Disk /dev/xvda: 53.7 GB, 53687091200 bytes, 104857600 sectors
    /dev/xvda1   *        2048     4098047     2048000   83  Linux
    /dev/xvda2         4098048    86018047    40960000   83  Linux
    /dev/xvda3        86018048   104857599     9419776   82  Linux swap / Solaris
    Disk /dev/xvdd: 53.7 GB, 53687091200 bytes, 104857600 sectors
    Disk /dev/xvde: 53.7 GB, 53687091200 bytes, 104857600 sectors
    Disk /dev/xvdb: 53.7 GB, 53687091200 bytes, 104857600 sectors
    Disk /dev/xvdc: 53.7 GB, 53687091200 bytes, 104857600 sectors
    Disk /dev/xvdf: 53.7 GB, 53687091200 bytes, 104857600 sectors
    
    

    Before you begin make sure that selected drives do not have existing RAID configured.

    # mdadm -E /dev/xvd[b-f]
    mdadm: No md superblock detected on /dev/xvdb.
    mdadm: No md superblock detected on /dev/xvdc.
    mdadm: No md superblock detected on /dev/xvdd.
    mdadm: No md superblock detected on /dev/xvde.
    mdadm: No md superblock detected on /dev/xvdf.
    

    Next step is to create partition on selected disks using fdisk. Follow below steps for each selected disks – /dev/xvd(b-f) in this example

    # fdisk /dev/xvdc
    Welcome to fdisk (util-linux 2.23.2).
    
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    
    Device does not contain a recognized partition table
    Building a new DOS disklabel with disk identifier 0x6845b853.
    
    Command (m for help): n
    Partition type:
       p   primary (0 primary, 0 extended, 4 free)
       e   extended
    Select (default p): p
    Partition number (1-4, default 1): 1
    First sector (2048-104857599, default 2048):
    Using default value 2048
    Last sector, +sectors or +size{K,M,G} (2048-104857599, default 104857599):
    Using default value 104857599
    Partition 1 of type Linux and of size 50 GiB is set
    
    Command (m for help): t
    Selected partition 1
    Hex code (type L to list all codes): fd
    Changed type of partition 'Linux' to 'Linux raid autodetect'
    
    Command (m for help): p
    
    Disk /dev/xvdc: 53.7 GB, 53687091200 bytes, 104857600 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0x6845b853
    
        Device Boot      Start         End      Blocks   Id  System
    /dev/xvdc1            2048   104857599    52427776   fd  Linux raid autodetect
    
    Command (m for help): w
    The partition table has been altered!
    
    Calling ioctl() to re-read partition table.
    Syncing disks.
    

    Once you’ve successfully created the partitions for all disks, you can verify the changes using below command

    # mdadm -E /dev/xvd[b-f]
    /dev/xvdb:
       MBR Magic : aa55
    Partition[0] :    104855552 sectors at         2048 (type fd)
    /dev/xvdc:
       MBR Magic : aa55
    Partition[0] :    104855552 sectors at         2048 (type fd)
    /dev/xvdd:
       MBR Magic : aa55
    Partition[0] :    104855552 sectors at         2048 (type fd)
    /dev/xvde:
       MBR Magic : aa55
    Partition[0] :    104855552 sectors at         2048 (type fd)
    /dev/xvdf:
       MBR Magic : aa55
    Partition[0] :    104855552 sectors at         2048 (type fd)
    

    Now create RAID device (/dev/md1 in below example) using all the newly created disk partitions

    # mdadm --create /dev/md1 --level=5 --raid-devices=5 /dev/xvdb1 /dev/xvdc1 /dev/xvdd1 /dev/xvde1 /dev/xvdf1
    mdadm: Defaulting to version 1.2 metadata
    mdadm: array /dev/md1 started.
    

    Note that it takes some time to complete the RAID creation. You can monitor the progress using below command. Below command will show you current % completed.

    # cat /proc/mdstat
    Personalities : [raid6] [raid5] [raid4]
    md1 : active raid5 xvdf1[5] xvde1[3] xvdd1[2] xvdc1[1] xvdb1[0]
          209575936 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [UUUU_]
          [=>...................]  recovery =  7.2% (3808256/52393984) finish=13.1min speed=61363K/sec
    
    unused devices: <none>
    
    

    But you prefer to watch screen till 100% completion then run below command. Result of this command will be persistent on the screen and will show you real time progress.

    # watch -n1 cat /proc/mdstat
    Every 1.0s: cat /proc/mdstat                            Mon Dec  2 09:41:04 2019
    
    Personalities : [raid6] [raid5] [raid4]
    md1 : active raid5 xvdf1[5] xvde1[3] xvdd1[2] xvdc1[1] xvdb1[0]
          209575936 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [UUUU_]
          [==>..................]  recovery = 13.9% (7335304/52393984) finish=12.1mi
    n speed=61622K/sec
    
    unused devices: <none>
    

    Once RAID creation is 100% you can run below command to see the summary of the RAID device configuration. RAID device is /dev/md1 in below example with 5 devices – /dev/xvd(b-f)1

    # mdadm --detail /dev/md1
    /dev/md1:
               Version : 1.2
         Creation Time : Mon Dec  2 09:39:05 2019
            Raid Level : raid5
            Array Size : 209575936 (199.87 GiB 214.61 GB)
         Used Dev Size : 52393984 (49.97 GiB 53.65 GB)
          Raid Devices : 5
         Total Devices : 5
           Persistence : Superblock is persistent
    
           Update Time : Mon Dec  2 09:53:20 2019
                 State : clean
        Active Devices : 5
       Working Devices : 5
        Failed Devices : 0
         Spare Devices : 0
    
                Layout : left-symmetric
            Chunk Size : 512K
    
    Consistency Policy : resync
    
                  Name : ip-10-10-10-207:1  (local to host ip-10-10-10-207)
                  UUID : 07f28a7b:3c70d798:1deecf9a:292ddd2c
                Events : 18
    
        Number   Major   Minor   RaidDevice State
           0     202       17        0      active sync   /dev/xvdb1
           1     202       33        1      active sync   /dev/xvdc1
           2     202       49        2      active sync   /dev/xvdd1
           3     202       65        3      active sync   /dev/xvde1
           5     202       81        4      active sync   /dev/xvdf1
    
    

    At this point we have RAID5 device created (/dev/md1). Now we need to create file system. In below example we are creating EXT4 file system

    # mkfs.ext4 /dev/md1
    mke2fs 1.42.9 (28-Dec-2013)
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=128 blocks, Stripe width=512 blocks
    13099008 inodes, 52393984 blocks
    2619699 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=2199912448
    1599 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks:
            32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
            4096000, 7962624, 11239424, 20480000, 23887872
    
    Allocating group tables: done
    Writing inode tables: done
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done
    
    

    Once the file system is created on RAID5 device, create the mount point and mount the RAID5 device on the same.

    # mkdir /mnt/ebs_r5
    # mount /dev/md1 /mnt/ebs_r5
    # df -h
    Filesystem        Size  Used Avail Use% Mounted on
    devtmpfs           32G     0   32G   0% /dev
    tmpfs              32G     0   32G   0% /dev/shm
    tmpfs              32G   17M   32G   1% /run
    tmpfs              32G     0   32G   0% /sys/fs/cgroup
    /dev/xvda2         39G  2.9G   34G   8% /
    /dev/xvda1        1.9G  234M  1.6G  13% /boot
    tmpfs             6.3G     0  6.3G   0% /run/user/1000
    /dev/md1          197G   61M  187G   1% /mnt/ebs_r5
    

    Also make sure you’ve added entry for new mount point in the /etc/fstab file. So that mount point will be persistent across system reboots.

    # vi etc/fstab
    /dev/md1                /mnt/ebs_r5              ext4    defaults        0 0
    
    

    Lastly most important step is to save the RAID configuration. Run below command to make sure RAID configuration is saved.

    # mdadm --detail --scan --verbose >> /etc/mdadm.conf
    

    At this point you’ve successfully created RAID5 device on Linux.

  • Linux – Configure iSCSI Initiator

    This blog is not to explain what is iSCSI but rather a reference to steps which an administrator should follow for configuring iSCSI on their Linux host (CentOS in my case)

    Prerequisites

    1. Make sure Linux host has IP connectivity to storage appliance which is acting as iSCSI target
    2. Storage appliance has iSCSI configured and service is running

    Steps

    Install iSCSI initiator on Linux host. Below is the example

    # yum install iscsi-initiator-utils
    Loaded plugins: ulninfo
    Resolving Dependencies
    --> Running transaction check
    ---> Package iscsi-initiator-utils.x86_64 0:6.2.0.874-11.0.1.el7 will be installed
    --> Processing Dependency: iscsi-initiator-utils-iscsiuio >= 6.2.0.874-11.0.1.el7 for package: iscsi-initiator-utils-6.2.0.874-11.0.1.el7.x86_64
    --> Running transaction check
    ---> Package iscsi-initiator-utils-iscsiuio.x86_64 0:6.2.0.874-11.0.1.el7 will be installed
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    =======================================================================================================================================================
     Package                                          Arch                     Version                                  Repository                    Size
    =======================================================================================================================================================
    Installing:
     iscsi-initiator-utils                            x86_64                   6.2.0.874-11.0.1.el7                     ol7_latest                   428 k
    Installing for dependencies:
     iscsi-initiator-utils-iscsiuio                   x86_64                   6.2.0.874-11.0.1.el7                     ol7_latest                    93 k
    
    Transaction Summary
    =======================================================================================================================================================
    Install  1 Package (+1 Dependent package)
    
    Total download size: 521 k
    Installed size: 2.6 M
    Is this ok [y/d/N]: y
    Downloading packages:
    (1/2): iscsi-initiator-utils-6.2.0.874-11.0.1.el7.x86_64.rpm                                                                    | 428 kB  00:00:00
    (2/2): iscsi-initiator-utils-iscsiuio-6.2.0.874-11.0.1.el7.x86_64.rpm                                                           |  93 kB  00:00:00
    -------------------------------------------------------------------------------------------------------------------------------------------------------
    Total                                                                                                                  1.1 MB/s | 521 kB  00:00:00
    Running transaction check
    Running transaction test
    Transaction test succeeded
    Running transaction
      Installing : iscsi-initiator-utils-iscsiuio-6.2.0.874-11.0.1.el7.x86_64                                                                          1/2
      Installing : iscsi-initiator-utils-6.2.0.874-11.0.1.el7.x86_64                                                                                   2/2
      Verifying  : iscsi-initiator-utils-6.2.0.874-11.0.1.el7.x86_64                                                                                   1/2
      Verifying  : iscsi-initiator-utils-iscsiuio-6.2.0.874-11.0.1.el7.x86_64                                                                          2/2
    
    Installed:
      iscsi-initiator-utils.x86_64 0:6.2.0.874-11.0.1.el7
    
    Dependency Installed:
      iscsi-initiator-utils-iscsiuio.x86_64 0:6.2.0.874-11.0.1.el7
    
    Complete!

    Once iSCSI package is installed then edit the iSCSI configuration file and enable node.startup = automatic. You will need to find node.startup in the config file and remove the # from start of the line. This will make sure that iSCSI is logging to target automatically on startup

    vi /etc/iscsi/iscsid.conf
    
    node.startup = automatic
    

    Now configure the iSCSI service to start automatically. Run below command

    # systemctl enable iscsid
    Created symlink from /etc/systemd/system/multi-user.target.wants/iscsid.service to /usr/lib/systemd/system/iscsid.service.
    
    

    Start iSCSI service

    # systemctl start iscsid
    

    Now at this point you’ve iSCSI enabled on your Linux server. If you want to view iSCSI initiator name of your server then run below command. Note that in most cases iSCSI initiator name will reflect into logged in initiators on your storage appliance in some cases you’ll need to provide the initiator name.

    # cat /etc/iscsi/initiatorname.iscsi
    InitiatorName=iqn.1988-12.com.oracle:b0ed4f9c9b9d
    

    Now let’s discover iSCSI target nodes using your storage system iSCSI IP address.

    # iscsiadm -m discovery -t st -p 172.16.1.11
    172.16.1.11:3260,2 iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.a2
    172.16.1.12:3260,1 iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.b2
    

    You can run below commands to list discovered iSCSI nodes

    # iscsiadm -m node
    172.16.1.11:3260,2 iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.a2
    172.16.1.12:3260,1 iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.b2
    
    or 
    
    # ls /var/lib/iscsi/send_targets
    172.16.1.11,3260
    
    # ls /var/lib/iscsi/nodes
    iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.a2
    iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.b2
    
    

    Once iSCSI nodes are discovered you can run below command to login into iSCSI target

    # iscsiadm -m node --targetname "iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.a2" --portal "172.16.1.11:3260" --login
    Logging in to [iface: default, target: iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.a2, portal: 172.16.1.11,3260] (multiple)
    Login to [iface: default, target: iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.a2, portal: 172.16.1.11,3260] successful.
    
    # iscsiadm -m node --targetname "iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.b2" --portal "172.16.1.12:3260" --login
    Logging in to [iface: default, target: iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.b2, portal: 172.16.1.12,3260] (multiple)
    Login to [iface: default, target: iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.b2, portal: 172.16.1.12,3260] successful.
    

    At this stage you’ve Linux host configured as iSCSI initiator and logged in successfully to target storage. Now you can ask storage admin to create LUNs and assign to Linux host.

    Once LUNs are assigned to Linux host you can run below command to scan new devices

    # iscsiadm -m session --rescan
    Rescanning session [sid: 1, target: iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.a2, portal: 172.16.1.11,3260]
    Rescanning session [sid: 2, target: iqn.1992-04.com.emc:cx.asfnsdbgfkdjfgdk.b2, portal: 172.16.1.12,3260]
    

    You can view new devices using fdisk -l or multipath -l command