welcome to symmetrix solutions enabler implementation. · 2016. 7. 7. · start the installation in...

Copyright © 2013 EMC Corporation. Do not copy - All Rights Reserved.

Welcome to Symmetrix Solutions Enabler Implementation.

Copyright © 1996, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,2012, 2013 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC2, EMC, Data Domain, RSA, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne, EMC Storage Administrator, Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation Technology, Common Information Model, Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz, DatabaseXtender, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab, EmailXaminer, EmailXtender, Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, ISIS, Max Retriever, MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink, PowerPath, PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, VisualSAN, VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso, YottaYotta, the EMC logo, and where information lives, are registered trademarks or trademarks of EMC Corporation in the United States and other countries.

All other trademarks used herein are the property of their respective owners.

© Copyright 2013 EMC Corporation. All rights reserved. Published in the USA.

Revision Date: June, 2013 Revision Number: MR-1CP-SYMMSEIC.ARNO.V3

1 Symmetrix Solutions Enabler Implementation


This course covers the installation and usage of commonly used options that govern the behavior of Solutions Enabler.



This course focuses on the preparation and installation of the EMC Solutions Enabler application, and the various parameters that are part of the setup process.



This module focuses on the preparation and process of installing Solutions Enabler on a host.

Symmetrix Solutions Enabler Implementation 4


Before you begin the installation process of Solutions Enabler, consult the E-Lab Interoperability Navigator for interoperability information. For detailed installation instructions and platform specific considerations, always refer to the EMC Solutions Enabler Installation Guide and Release Notes. The documentation is available at Support.EMC.com.

Think about the questions like, How many Symmetrix arrays are in your environment that you need to discover on this host? Secondly, consider what your needs for gatekeepers are. Are there any devices that you would definitely not use as gatekeepers? Conversely, are there any devices that you would definitely want to designate as gatekeepers? Are there any devices reserved for use by the RDF Daemon? This may be true if you have an SRDF/Star environment.

The number of hosts is also important in your management environment. Is there more than one? If so, do you want to share group definitions? (If yes, you need to turn on GNS. Furthermore, you need to consider how your environment will be accessed and how many others will be managing your Symmetrix arrays). Do you wish to implement Symmetrix Access Controls? Do you want to assign certain roles to certain users?

Finally, you need to prepare your specific platform. On a Windows host, you need to determine which daemons you want to start after the installation is complete. On a UNIX host that is running AIX or OSF1, all binaries and libraries will be installed under /opt/emc, as these operating systems do not allow changes to the installation destination path. Check to make sure you have sufficient disk space in that directory. If not, create a soft link (by executing 'ln -s NewInstallationDir /opt/emc’) prior to running the installation. Just make sure that root has write permissions to the “NewInstallationDir”.



Solutions Enabler runs on a wide range of operating systems and works with specific Symmetrix Enginuity™ versions. Host requirement can be found at E-Lab™ Interoperability Navigator (at http://elabnavigator.EMC.com).

For security settings refer to the Solutions Enabler Security Configuration Guide for information on how security settings work in Solutions Enabler and how to configure them.

If you are upgrading from a previous version, create copies of the host database and configuration directories; these copies will be useful should you want to roll-back to the previous version of Solutions Enabler.



Depending on the platform, mount or load the CD so that the installation software can be accessed from the host, then start the installation process. For detailed installation instructions, please refer to the EMC Solutions Enabler Installation Guide.

The Microsoft Windows installation uses the Microsoft installer and provides an interactive graphical interface. The UNIX native installations are initiated by running an installation shell script.

During the installation process, you are required to enter the destination directory for such structures as db, log, and configuration directories. The installation process also requires you to identify any installation option that is required.



The SYMAPI distribution kit for Microsoft Windows uses the Install Shield Wizard.

Specify the Destination Folder for the installation; the default location is C:\Program Files\EMC\.

Then, choose the Setup Type. The three options are:

• Typical, which installs a subset of the kit that was highlighted on the previous page,

• Custom, which allows the user to choose each component that is appropriate for the environment, and lastly,

• Complete, which installs all the components of the kit



If Custom setup is chosen, it is possible to individually select or deselect the optional components.

BASE_COMPONENT, SYMCLI_COMPONENT, and SYMRECOVER_COMPONENT are installed with a Typical install.

JNI_COMPONENT and SRM_COMPONENT are optional components, which can be selected with a Custom install.



For a Typical installation on Windows, the user is given an option to install and start the daemons listed on the Service List screen. The Base Daemon will always be installed and started. The daemons that are grayed out were not part of the Typical installation, and therefore cannot be started. In this example, the SYMAPI Server Daemon and the Event Daemon have been chosen.



To install Solutions Enabler in a UNIX environment, execute the script ‘./se7600_install.sh -install’ to start the installation in the interactive mode. This starts the installation process, if you wish to proceed with a silent installation, use the ‘-silent’ argument. Similar to Windows installation, you need to enter the installation directories and pick out your components. Some of the daemons can be setup to run as non-root user.

In the interactive mode, you will be prompted with a number of questions. The square brackets in your student guide indicate the default value.

If you are installing Solutions Enabler on a Linux host for the first time, you will be asked for the following:

Do you want to import public key for verifying Digital Signatures? [Y]:

Install root directory [/opt/emc]:

Working root directory [/usr/emc]:

You will then be prompted to install each of the components, again, the square brackets in your student guide indicate the default value.

Install All EMC Solutions Enabler Shared Libraries and Run Time Environment? [Y]: This is the BASE Component

Install Symmetrix Command Line Interface SYMCLI? [Y]:

Install Option to Enable JNI Interface for EMC Solutions Enabler APIs? [N]:

Install EMC Solutions Enabler SRM Components? [N]:

Install EMC Solutions Enabler SYMRECOVER Components? [Y]:

Finally, you will be prompted to specify whether to change the default UNIX file permissions.

Do you want to change default permission on /var/symapi directory from [755]? [N]:

For more information about the Solutions Enabler installation, please consult the EMC Solutions Enabler Installation Guide.



After completing the installation, set the environment variables or paths so that you can directly access both the SYMCLI commands and the online help (the ‘man’ pages). The online help path allows direct access to descriptions of the command set.

The lower half of this slide shows how to add the SYMCLI binary directory to the PATH and the MANPATH environment variables. For Windows, add the binary path; however, manual pages setup is not needed. You can find them automatically in the ‘man’ and ‘storman’ folders of the SYMCLI directory.

After the installation is completed and the paths have been set, the Symmetrix arrays can be discovered and the license keys for the various Symmetrix features can be entered. We will discuss discovery in the next page and license management in the next module.

SYMCLI also provides additional environment variables that you can preset to streamline your command session. Set these variables to common argument values for a series of associated commands so that you do not have to use as many key strokes in your session. We will discuss more about ‘Environment Variables’ in Module 3 of this eLearning.



Before using the SYMCLI commands, you need to run the symcfg discover command to build your configuration (SYMAPI) database. This needs to be done once after installation, and after any changes are made to your Symmetrix configuration. The symcfg discover command scans all SCSI buses, collects information about all the arrays and devices found, and rebuilds the database with the collected device information and parameters from all local and remotely attached devices. You can limit the discovery to just Symmetrix arrays by specifying the -symmetrix option.

The SYMAPI configuration database is sometimes referred to as the host configuration database, SYMAPI database (because of how the file is named), or the Symmetrix database file. All of these names are referring to the same configuration database file, symapi_db.bin.

On UNIX, the default pathname for the configuration database file is:

/var/symapi/db/symapi_db.bin

On Windows, the default configuration database path is:

C:\Program Files\EMC\Symapi\db\symapi_db.bin

Use the symcfg verify command to determine if the host configuration database file is synchronized with the current configuration of a specific Symmetrix array. In addition, the symcfg list -status command provides a list of all arrays connected to your host, whether the configuration has changed, and if the array was discovered during the last discovery operation. This slide shows the examples of symcfg list -status and symcfg verify commands.



This module covered the Solutions Enabler installation process.



This module focuses on the different methods of licensing the EMC Solutions Enabler application after it has been installed.



For Symmetrix arrays running Enginuity version 5874 and prior, Solutions Enabler uses host-based license keys for all the Symmetrix features. Before you can use your installed Solutions Enabler components, you must first enable each component’s functionality in the API by entering the appropriate host-based license keys.

For Symmetrix arrays running Enginuity 5875 and later, Electronic Licensing (eLicensing) is used. eLicensing is an end-to-end license tracking solution to help you manage, track, and comply with software license entitlement. With the introduction of eLicensing, Symmetrix licensing is moving from a host-based model to a Symmetrix-based model with the licenses now being stored in a feature registration database on the Symmetrix array. However, there are some Symmetrix features that still use host-based licenses.

When installing licenses with eLicensing, you obtain license files from Support.EMC.com, copy them to a Solutions Enabler or Unisphere for VMAX host, and push them out to Symmetrix arrays. Each license file fully defines all of the entitlements for a specific array, including the type of license (Permanent or Evaluation), the licensed capacity, and the date the license was created.

For more details on the specific features that require host-based or Symmetrix-based licenses, please refer to ‘Chapter 3 – Licensing your Software’ in the EMC Solutions Enabler Installation Guide.



To install a host-based license:

• Use ‘symlmf add -type se -license LicenseNumber’ command to install a license key on a host.

• Use ‘symlmf list -type se’ command to list the licenses installed on the host.

Host based licenses can be deleted as well.

The host-based licenses are stored in the symapi_licenses.dat file, which is located in the ‘config’ folder under the ‘SYMAPI’ folder.



To install the licenses from a license file to a Symmetrix array’s feature registration table:

• Obtain a license file from Support.EMC.com and copy it to your host.

• Use ‘symlmf add -type emclm -sid SymmID -file FileName -v’ command to push license file to the Symmetrix array.

To display the current Symmetrix-based licenses activated by a license file, use the command:

symlmf list -type emclm -sid SymmID

A sample output of the symlmf list command is shown on this slide (the truncated output only shows the SYMM_VMAX_ENGINUITY entitlement).



The symlmf query command displays the current state and the usage numbers for all licenses activated on a Symmetrix array.

For example, to display the state and the usage number for all activated licenses on Symmetrix 842, enter:

symlmf query -type emclm -sid 842

A sample output of the symlmf query command is shown on this slide (the output is truncated and only shows the SYMM_VMAX_ENGINUITY entitlement).

Note that Symmetrix-based licenses cannot be deleted.



This module covered Solutions Enabler licensing.



This module focuses on the function of the SYMAPI options file and the various parameters included, which can be enabled.



In the SYMAPI config directory there is an ‘options’ file. This is a critical file containing parameters that can change the default behavior of SYMCLI operations, and SYMAPI calls and their control actions. You can use this file to restrict some things globally, as well as customize and streamline the command line coding for your specific environment.

Next we will look closer at most commonly used options. To see a more extensive list of these options, consult the Solutions Enabler Symmetrix CLI Command Reference.



In a common repository, SYMAPI_USE_GNS stores and maintains SYMAPI device group and composite group definitions across Symmetrix arrays that are visible to all locally-attached hosts. This is for use by Group Name Services (GNS) daemon, which will be described later. By default, this is disabled. If you enable this, then GNS is used for group operations as long as the default SYMAPI database file is being used.

SYMAPI_USE_RDFD allows the creation of RDF_CONSISTENCY composite groups to be managed by the RDF Daemon. The RDF Daemon is discussed in more detail later. The purpose of this option is to allow the creation of RDF_CONSISTENCY composite groups to be managed by the RDF Daemon. This is disabled by default.

SYMAPI_WAIT_ON_LOCKED_GK specifies whether to wait when a locked gatekeeper device is encountered. Turn on this feature where gatekeeper device availability is scarce. It will force SYMCLI to wait when a locked gatekeeper device is encountered.



The daemon_options file contains a set of parameters that can be modified to change daemon behavior. The file contains editable behavior parameters set to certain optional defaults in the line entries. To remove any parameter option, remove the line entry, rename the file, or comment the line by adding a pound sign (#) at the beginning of the line entry. This slide lists some commonly used parameters. Inquiry timeout specifies how long inquiry results are to remain in application cache before new data is retrieved from the array.

Some parameters include question marks (??), which means that you can use this parameter to specify to a particular daemon.

Fill in the proper name by replacing the question marks when you edit that part of the file. Log file size determines how long each log file should grow before wrapping to the next log file. Autorestart specifies whether the watchdog daemon will restart this daemon.

Each daemon reads this file as it starts, and applies any settings within it that are applicable. It is important to know the various names for the daemons when reading and editing this file.

The Base Daemon is storapid, the GNS Daemon is storgnsd, the RDF Daemon is storrdfd, the Event Daemon is storevntd, the STP Daemon is storstpd, the Watchdog Daemon is storwatchd, and the SYMAPI Server Daemon is storsrvd.

Some of these daemons are described in more detail later in the training.



SYMCLI provides a number of ‘Environment Variables’ that you can preset to streamline your command session. Set these variables to common argument values for a series of associated commands so that you do not have to use as many key strokes in your session.

To see what Environment Variables you can set, enter symcli -env. To see a list of what ‘Environment Variables’ you have set, enter symcli -def. This slide lists some of the environment variables that are commonly used to streamline SYMCLI functions.

SYMCLI_COMMAND_SCOPE sets the scope of the device selection process. By default, this is disabled. If you enable it, it will limit the operation to only the devices within the scope of the command and no others.

SYMCLI_MODE specifies the command output reporting style to be compatible with prior SYMCLI versions. This is very useful if you have scripts that you have been using with previous versions of Solutions Enabler that rely upon SYMCLI functions displaying output in a specific way.

SYMCLI_OUTPUT_MODE is also useful for shell scripter users. This can be set to Standard (default), XML, XML_ELEMENT, or XML_ATTRIBUTE.

SYMCLI_NOPROMPT is set to 0 (false) by default. If you do not change this, you will always get verification prompts when executing configuration changes, and will have to use ‘-nop’ for any instance where you want to avoid it. If, however, you set this environment variable to 1 (true), you can avoid this entirely, every time you make changes.



Both SYMCLI_CLONE_COPY_MODE and SYMCLI_CLONE_EMULATION are for TimeFinder/Clone activities. The former defaults to COPY_DIFF, but can also be set to NOCOPY_NODIFF, COPY_NODIFF, PRECOPY_NODIFF, PRECOPY_DIFF, or VSE_NODIFF. This setting specifies the mode in which Clone sessions are created. The latter specifies whether TimeFinder commands should be mapped to Clone commands by default. By default, this is disabled.

SYMCLI_MULTI_VIRTUAL_SNAP specifies if more than 16 Snap sessions can be created on the same source device. By default, this is disabled.

Note that on Symmetrix VMAX 40K arrays, the SYMCLI_MULTI_VIRTUAL_SNAP setting has no effect. All the Snap sessions on VMAX 40K arrays always use the multi-virtual snap feature.



SYMCLI_RCOPY_COPY_MODE specifies the mode in which RCOPY sessions are created. There are more options such as COPY_DIFF, NOCOPY_DIFF,COPY_NODIFF, NOCOPY_NODIFF, PRECOPY_DIFF or PRECOPY_NODIFF.

SYMCLI_REMOVE_SYMS, when set to 1 (true), will, upon discovery, remove from the configuration database any record of a Symmetrix array and its dependent devices and device groups when a Symmetrix array is no longer reachable.

SYMCLI_SKIP_ON_FAILURE, when set to 1 (true), will cause the symcfg discover command to skip over any Symmetrix array encountered in an error state. This allows the command to complete the scan of the remaining units. If you do not change this, and keep it at 0 (false), the discovery will scan all bus-connected devices, but then will fault as it fails to complete the interrogation of all the Symmetrix arrays.

SYMCLI_VERBOSE enables the verbose response mode specifically for SRDF and BCV operations.

SYMCLI_WAIT_ON_DB waits to obtain a lock on the Symmetrix configuration database when locked by another user. By default, a busy database returns an error.

SYMCLI_WAIT_ON_GK causes the SYMCLI to wait for the retrieval of Symmetrix information when all gatekeepers are busy. Otherwise, a busy gatekeeper generates an error.

For a more extensive list of ‘Environment Variables’, please see the Solutions Enabler Symmetrix CLI Command Reference.



The symavoid file affects the operation of ‘symcfg discover’ so that it does not look for devices that belong to Symmetrix arrays specified in this file. This may be useful if there are multiple Symmetrix arrays connected to the host that you want SYMCLI to ignore. The Symmetrix avoidance file is formatted with 12-character Symmetrix IDs, with one Symmetrix ID per line.

If you create this file, save it in the config subdirectory of the SYMAPI directory.



This module covered the Solutions Enabler options files.



This module focuses on the usage and characteristics of the gatekeeper devices.



Solutions Enabler is an EMC software component used to manage the storage features of Symmetrix arrays. It receives user requests via SYMCLI, GUI, or other means, and generates system commands that are transmitted to the Symmetrix array for action.

Gatekeeper devices are LUNs that act as the target of command requests to Enginuity-based functionality. These commands arrive in the form of disk I/O requests. The more commands that are issued from the host, and the more complex the actions required by those commands, the more gatekeepers that are required to handle those requests in a timely manner.

A gatekeeper is not intended to store data, and is usually configured as a small three cylinder device (Approx. 3 MB). Gatekeeper devices should be mapped and masked to single hosts only, and should not be shared across hosts.

Note: For specific recommendations on the number of gatekeepers required for all Symmetrix configurations, refer to EMC Knowledgebase Solution emc255976, available at the Online EMC Support Website.



All Symmetrix devices visible to a host when using SYMCLI commands are potential gatekeeper candidates. Solutions Enabler can utilize any available device as a gatekeeper, but it selects a gatekeeper based upon a pre-established priority list.

The gatekeeper priority list includes all gatekeeper candidates prioritized from the highest to the lowest:

• First, are those devices that are smaller than 10 cylinders each and are marked by the

Symmetrix array with the inquiry gatekeeper flag.

• Second, are standard non-RDF and non-meta devices.

• Third, are R1 devices.

• Fourth, are R2 devices.

• Finally, the VCM device on DMX arrays or the ACLX device on VMAX family can also be used

as gatekeeper devices.

Solutions Enabler starts with the highest priority gatekeeper candidate. If there are no gatekeeper candidates at that priority, or the device is not accessible or currently in use, then Solutions Enabler tries to use the remaining gatekeeper candidates, in priority order, until it successfully obtains a gatekeeper, or it has tried all gatekeeper candidates. When Solutions Enabler successfully obtains a gatekeeper, it locks the device, and then processes the system commands. Once Solutions Enabler has processed the system commands, it closes and unlocks the device, freeing it for other processing.

BCV devices and Virtual Devices (VDEVs) are excluded from the gatekeeper candidate list.



The gkselect file specifies only those Symmetrix devices to be used as gatekeepers. The file contains physical device names, with one PdevName (for example, /dev/rdsk/c2t0d1s2) per line.

The gkavoid file specifies the Symmetrix devices that should not be used as gatekeepers. The gatekeeper avoidance file contains physical device names with one PdevName per line.

The use of gkselect and gkavoid files is optional. When determining which of these files is appropriate for your environment, consider the following:

a) If too many gatekeepers are in the gkavoid file, Solutions Enabler may end up selecting one of your production devices as a gatekeeper. This could potentially cause significant impact on host application performance.

b) If there are not enough gatekeepers in the gkselect file, Symmetrix control operations may time out. However, no extra maintenance is required when adding new devices, as it would be necessary when using only the gkavoid file.

If there are no devices listed in the gkselect file for a particular Symmetrix array, or if all of the devices listed in the file are offline or do not exist at the time the file is read, then normal gatekeeper selection rules apply, as explained in the previous slide. This may also result in Solutions Enabler choosing a production device as a gatekeeper, which could impact host application performance.

If a device is listed in both the gkavoid file and the gkselect file, the device will be avoided.



Gatekeeper devices must be at least as large as the minimum volume size accessible by your host, which are usually 3 cylinders or 2.8 MB. Consult your host documentation for the minimum device size accessible by your particular host to determine the minimum gatekeeper device size for your environment.

(Multi-path Gatekeeper support): Starting with Enginuity 5876 and Solutions Enabler V7.4 and higher, multi-path gatekeeper support has been expanded beyond using EMC PowerPath to include a limited set of third-party multi-pathing solutions on a limited set of platforms. See E-Lab Navigator for an up-to-date list of supported Multi-pathing Software.

(Thin Gatekeeper devices): Starting with Enginuity 5876 and Solutions Enabler 7.4 or higher, the gatekeeper selection algorithm ignores the fact that a device happens to be a thin device when selecting gatekeeper candidates. Thin gatekeeper devices function identically to standard gatekeeper devices. The thin gatekeeper device does not have to be bound to a thin pool. Hyper-V thin gatekeeper devices must be bound to a pool.

(Gatekeeper Locking): Within a SYMCLI session, gatekeeper and database locks are used to avoid conflicts in accessing a Symmetrix array by way of gatekeepers or the configuration database. If the requirements are not within the bounds of the default semaphore parameter settings on a UNIX system, the UNIX kernel must be reconfigured. If the UNIX kernel is not reconfigured, the SYMCLI gatekeeper and database locking may fail.



To display information on the number of gatekeeper candidates, dedicated gatekeepers, unique gatekeepers, open gatekeepers and gatekeeper utilization information, use the following command:

stordaemon action storapid -cmd show –gk_stats -sid SymmID

In the example on the slide, we can see that the host sun187 has access to 6 dedicated gatekeeper devices on Symmetrix 495.



To display which devices are gatekeeper candidates and the state of each gatekeeper

(opened or closed), use the following command:

stordaemon action storapid -cmd show –gk_pdevs -sid SymmID

A value of “X” in the “D” column indicates that a given device is a dedicated gatekeeper.

In the example shown, we can see that the first device is a dedicated gatekeeper and its state is currently open (OPN).

The legend for the output is shown in the notes (below) of your Student Guide for reference:

(Flags:

In gk(A)void file : X = True, . = False

In gk(S)elect file : X = True, . = False

Is a (D)edicated GK: X = True, . = False

Is a (C)hild device: X = True, . = False

Is a (V)CM/ACLX dev: X = True, . = False

State:

OPN = Device is open as a gatekeeper

INV = Device is invalid

CLS = Device is closed)



The ACLX device was first introduced in Enginuity 5874 with the Symmetrix VMAX Series arrays. The ACLX device is similar to the to the VCM device used in DMX arrays and is used for storage provisioning using Auto-Provisioning Groups on Enginuity 5874 or higher. The ACLX device can function as a gatekeeper in Symmetrix VMAX family of arrays.

The host communicates with the array through a pass-through device with the ACLX attribute. Through Solutions Enabler, you can designate an ACLX device using the symconfigure command to set the device attribute equal to ACLX. For more information about the ACLX flag and using symconfigure, please refer to the EMC Solutions Enabler Array Controls CLI guide.



This module covered Solutions Enabler gatekeepers.



This module focuses on the function and files used for Solution Enabler Daemons.



To improve the performance on a number of applications or scripts running at once, you can employ Solutions Enabler daemons (services) that run in the background with root privileges to a local Symmetrix storage resource. Applications do not have to run as a privileged user, but when your host is locally-connected to the Symmetrix array, applications and daemons must reside in that host. However, for client/server systems, the storage management applications reside in the client, and most of the daemons must reside in the SYMAPI server. The one exception to this is the Event daemon, which runs on both the client and the server.

The daemons are all installed to the ‘daemons’ subdirectory of the SYMAPI directory where Solutions Enabler is installed.

The Solutions Enabler daemon processes are controlled by the command stordaemon. Use this command to start, stop, or query any, or all daemons’ statuses. This slide lists some stordaemon commands that may come in handy. The user can chose which daemons they want to start during the installation, but if you want to choose afterward to start another daemon, you can use the command stordaemon start. Recall that we spoke of editing the daemon options file. For certain settings, you can alternatively use the stordaemon setvar command to change daemon behavior.



The Base Daemon (storapid) provides centralized gatekeeper device management for all the Solutions Enabler applications requiring access to Symmetrix arrays, along with the GNS and RDF Daemons. This alleviates contention when there are limited gatekeeper resources available and also eliminates the need for every client to constantly select, open, lock, and ping for an available gatekeeper device for every online function.

Additionally, the Base Daemon monitors Symmetrix External Locks (SEL) and Device External Locks (DEL), and automatically releases any locks held by a crashed application. It also eliminates the need for Solutions Enabler applications to run as root.

Each host running an instance of the RDF Daemon (storrdfd) must also run the Base Daemon, as it requires the use of the gatekeeper management services.

When you are trying to troubleshoot Base Daemon behavior, find the log file in the SYMAPI directory under the ‘log’ subdirectory. All the SYM API logs are titled in the form storapid-yyyymmdd.log. Find the one that is the most recent, and open it. Conversely, if the logfile_type option is not set to ‘dated’, then you will have just two logs, namely, storapid.log0 and storapid.log1.



The Event Daemon (storevntd) acts as a clearing house for all the Solutions Enabler events on a host. In most cases, events are delivered by a producer to the Event Daemon, and then forwarded to any client applications that have registered an interest in them.

If you are in client/server mode, events are forwarded from the Event Daemon on the remote (server) host to the local (client) host, and from there to the client applications. An alternative mode of operation for the Event Daemon works, such that it autonomously watches for conditions of interest independently of any applications. Option settings specify the events to be monitored and how they are to be logged when they occur.

This slide lists some of the information that the events may contain.

By default, the Event Daemon writes diagnostic messages to the log files storevntd.log0 and storevntd.log1, both located in the SYMAPI’s log directory.



Group Name Services provide a common repository to store and maintain SYMAPI device group (DG) and composite group (CG) definitions across Symmetrix arrays that are visible to all locally attached hosts. By default, with GNS disabled, group definitions are stored in the local SYMAPI configuration database file on the host that created the group. Enabling GNS enables group definitions to be stored on the Symmetrix array in a shared GNS repository.

This shared GNS repository is visible to any GNS-enabled locally-attached host enabling these hosts to perform control operations, regardless of which host initially defined the group. In addition, if one host goes down, you can still perform SYMCLI control operations from another local host in your Symmetrix environment.

In the GNS-enabled environment, each host performing management operations must run an instance of the GNS Daemon.



The Symmetrix environment should be configured to support GNS. GNS use is optional and can be either enabled or disabled on each host via the SYMAPI options file setting SYMAPI_USE_GNS, which we mentioned earlier in the course when we talked about the various options file parameters. The server may have to be restarted for the options to take place.

In the case of client/server mode, the SYMAPI server acts as the GNS client, and the server's SYMAPI options file (SYMAPI_USE_GNS) determines whether GNS is enabled for the client. If GNS is enabled and the client is caching (SYMAPI_CONN_TYPE_REMOTE_CACHED), then the client checks periodically with the server to determine if the group definitions that it is caching need to be updated. The default is one second.

When a client needs group information, it validates its cached group definitions with the server if the time since the last check is longer than the default value or whatever new value is set for this option.

Diagnostic messaging is written to storgnsd.log0 and storgnsd.log1 in the SYMAPI’s log directory.



The RDF Daemon (storrdfd) is optional, but provides consistency for SRDF/A MSC and RDF-ECA composite groups.

The RDF Daemon runs on each host where RDF consistency is required. If GNS is enabled, the RDF daemon relies on GNS to propagate CG definitions to all pertinent hosts. If GNS is not enabled, you must explicitly create the exact same CG definitions on each participating host.

The RDF Daemon records its log messages into the files storrdfd.log0 and storrdfd.log1 in the SYMAPI’s log directory. Information you will find in the log is listed on this slide.



The SYMAPI server runs in a background process started by the ‘stordaemon start storsrvd’ command. The server reads its configuration from the daemon options file and records log information in its own log file set, which resides in the SYMAPI log directory. The server listens for SYMAPI sessions and management requests initiated by the stordaemon command. It also listens for management requests from the system operator console.

While session threads come and go, the server continues to accept connection requests until an operator enters a command to initiate the server shutdown process. The operator has the choice to end the server safely, where the server will wait for all current sessions to terminate on their own, or to end the server immediately, in which case the server will simply terminate all current session threads without giving them a chance to end on their own.

The SYMAPI Server Daemon listens for SYMAPI sessions from remote clients and responds to management requests from authorized users of the stordaemon command on the same host. You can create an optional nethost file in the /SYMAPI/config directory that lists trusted hosts and users so that the server knows who to authorize when clients execute remote SYMAPI connections. If you do not create this file, then all the SYMAPI clients are permitted to connect to the SYMAPI server.

If all the clients and the server are SSL-capable, the server can be configured to run only secure sessions.



This module covered Solutions Enabler Daemons.



This module focuses on the EMC Solutions Enabler Virtual Appliance, which is used with VMware servers.



The Solutions Enabler Virtual Appliance is a VMware ESX server virtual machine that provides all the components you need to manage your Symmetrix environment using the storsrvd daemon and Solutions Enabler network client access. These components are:

• EMC Solutions Enabler V7.6, solely intended as a SYMAPI server for Solutions Enabler client access,

• Linux OS SUSE 11 SP1 JeOS,

• SMI- S Provider V4.6, and

• Solutions Enabler Virtual Appliance Configuration Manager

The Virtual Appliance runs the SUSE 11 SP1 JeOS operating system. It is important to note that root login is not supported on the Virtual Machine. Local login is restricted to the seconfig account with restricted access.

The Solutions Enabler Virtual Appliance Configuration Manager allows the user to perform a number of tasks that cannot be performed directly by the Virtual Appliance. We will take a closer look at the SE Virtual Appliance Configuration Manager on the next slide.

The UNI vAPP Virtual Appliance OVF archive file can be downloaded from Support.EMC.com.



The Solutions Enabler Virtual Appliance Configuration Manager is a browser-based configuration tool. This tool enables you to perform configuration tasks that are not available from the Virtual Appliance directly. The list of tasks is shown on this slide. In addition to these tasks, one can also monitor the status of the Solutions Enabler daemons and discover storage arrays from this web interface. The import/export of persistent data is used when an update to the Virtual Appliance is required.



The latest version of the Solutions Enabler Virtual Appliance can be downloaded from Support.EMC.com. The OVA file contains the OVF archive needed to deploy the appliance.

Solutions Enabler Virtual Appliance can be installed on ESX/ESXi Server v4.0 or higher, and VMware vSphere Client is required for the deployment.

Solutions Enabler Configuration Manager requires a supported browser (Internet Explorer 6.0-8.0, Firefox 3.5 or higher) with cookies and javascript enabled. The browsers should also have Flash Player 11.2 plug-in installed.



To deploy the Solutions Enabler Virtual Appliance, launch the VMware client and login to your Virtual Center Server or to your ESX Server, and then import the Solution Enabler Virtual Appliance OVF archive.

Detailed deployment instructions are documented in ‘Chapter 8’ of the EMC Solutions Enabler Installation Guide.

The network settings are configured by specifying either a DHCP server or a static IP address for the appliance. Once the appliance is set up, it can be accessed via a browser using port 5480 at the address that was set up during the previous step.



This module covered the Solutions Enabler Virtual Appliance.



Listed are the key points covered in this course. Please take a moment to review them.

This concludes the training. Please proceed to the course assessment.


welcome to symmetrix solutions enabler implementation. · 2016. 7. 7. · start the installation in...

Documents