Technical Report

Operational Best Practice: Naming Convention

Eyal Horowitz, NetApp Contributions by: Alan Parker, Antonio Neto, and Ken Hillier April 2013 | TR-4158

Operational Best Practice for Naming Convention at <Customer>

Beyond the technical best practices laid out by NetApp in the technical manuals, there are norms, policies, and configuration items that are necessary to enable the successful operation of any feature in a specific customer environment. This document captures those necessary items.

TABLE OF CONTENTS 1 2 3 Introduction ........................................................................................................................................... 3 Current State (the Challenge) .............................................................................................................. 3 Recommendation.................................................................................................................................. 3

Operational Best Practice Naming Convention

1 Introduction
The idea of creating names based on a certain key or algorithm was adopted many years ago with the intent of allowing useful information to be shared in a common way using names based on defined rules. For instance, in cities, streets are numbered with east-west/north-south information (such as 5NS or 10EW) or names such as main, river, or bourbon for the location of what can be found there. Similarly, it is always a best practice to use names that support meaningful documentation of the location, data information, priority, and use of that object. For example, NYC_Main_Data_Center is more appropriate than DC1 and Customer_Info_Dump_2012_10_01 more appropriate than Data_Dump.

2 Current State (the Challenge)

Although this sounds like a necessary and obvious requirement, many organizations do not have a standardized method for naming and tracking their data, leading to an increase in storage use and operational cost. Data growth and the cost of managing it over the years are often major sources of many IT storage management challenges and much budget overspending. Naming conversion logic is becoming more common and widely adopted to assist with these types of challenges, and adopting its use is becoming the de-facto way in the marketplace.

3 Recommendation
Naming conversion is a procedure accompanied by a manual or automated process and concludes with a validation step to enable the appropriate use of the storage based on the procedure. Many customers already have naming standards, and the following recommendations are used as supporting guidelines and supplements to the existing procedures: Many systems do not distinguish between uppercase and lowercase. Do not use any special characters, spaces, or hyphens. Storage systems do not accept hyphens ( -) in many names, and many operating systems trim special characters, making different names look the same to the OS. Any naming convention should be short and concise (meaningful). This will limit typing for those who do not use the mouse all the time. Refer to the customers infrastructure operations or architecture team for their naming standards. Location code (23 characters) + environment (23 characters) + device type (34 characters, such as 'pSTR') + running number (3 digits) Example: <Loc><Env><pSTR>### - ATL_PRD_pSTR001 Vserver (clustered Data ONTAP) Can be multiple options but must be consistent across the storage estate: Generic documentation default: vs0, vs1 By application: oracle, vmware, putty By department: billing, hr, eng, projectX Customer codenames: standardized naming conventions that a customer might have already established Keep the name short as it can be used within LIF names or possibly failover groups

Note:

Storage system

Note:

Operational Best Practice Naming Convention

vFiler (7-Mode)

Environment/use (23 characters) + service type/SLO (3 characters, such as 'PRD' or TST) + device type (34 characters, such as 'vSTR') + running number (3 digits) Example: <Env><ENV><vSTR>### - HR_PRD_vSTR001

System aggregates

aggr<number##>_nodename<##> This keeps all the system aggregates together and at the top of the list. It also differs enough to make it easy to use some regular expressions to match system or data aggregates. Example: aggr00_host01 number ##: double-digit format

Aggregate

Data aggregates

Nodename<##>_Type_Instance<##> Example: host_01_sas_01 -or- host_01_sas_aggr1 Location and architecture are clearly identifiable and simplify the useAlternative - Tiering style Nodename<##>_Tier_instance<##> Example: host_01_T1_aggr1 Tiers need to be defined and standardized across all storage platforms

Volume

<application>_<environment>_<datatype><number###> application: application or DB instance name environment: prd, stg, tst, qa, trn, dev, sbx datatype: boot, iboot, data, userdata, log, logs data, oradata number#: triple-digit format Application volume name example: myapp_prd_data001

Application volume full path example: /vol/myapp_prd_data001 Alternative: by function: if the function of the volume: vmware datastore = vmdatastore1 oracle bin = orabin

oracle data = oradata Clustered Data ONTAP junction path or mount point: /eng/proj_x/group01 <--> eng_proj_x_group01 Qtree (Data ONTAP 7-Mode only) <application>_<environment>_<datatype><number###> application: application or DB instance name environment: prd, stg, tst, qa, trn, dev, sbx datatype: boot, iboot, data, userdata, log, logs data, oradata

number#: triple-digit format Alternative: by function:

Operational Best Practice Naming Convention

 LUN

vmware datastore = vmdatastore1 oracle bin = orabin oracle data = oradata

<application>_<environment>_<datatype><number###>.lun application: application or DB instance name environment: prd, stg, tst, qa, trn, dev, sbx datatype: boot, iboot, data, userdata, log, logs data, oradata number###: single-digit format Application LUN name example: myapp_prd_data001.lun App. LUN full path example: /vol/myapp_prd_data001/myapp_prd_data001.lun

FC boot volume

<servername>_boot<number###> servername: Hostname, NodeName, FrameName, VIO, LPARName number###: triple-digit format FC boot volume name example: myserver_boot001 Volume full path example: /vol/myserver_boot001

FC boot LUN

<servername>_boot<number###>.lun servername: Hostname, NodeName, FrameName, VIO, LPARName number###: triple-digit format LUN name example: myserver_boot001.lun LUN full path example: /vol/myserver_boot001/myserver_boot001.lun

iSCSI boot volume

<servername>_iboot<number###> servername: Hostname, NodeName, or ServerName number###: triple-digit format iSCSI boot volume name example: myserver_iboot001 Volume full path example: /vol/myserver_iboot001

iSCSI boot LUN

<servername>_iboot<number###>.lun servername: Hostname, NodeName, or ServerName number###: triple-digit format iSCSI LUN name example: myserver_boot001.lun LUN full path example: /vol/myserver_boot001/myserver_boot001.lun

Igroup

<servername>_<datatype><number###> servername: Hostname, NodeName, FrameName, VIO, LPARName datatype: boot, iboot, data, logs Another option is to include i of f for protocol type

Operational Best Practice Naming Convention

 number###: triple-digit format Example: myserver_iboot001 NFS application data volume <application>_<environment>_<datatype><number###> NFS application data qtree application: application or instance name environment: prd, stg, tst, qa, trn, dev, sbx datatype: boot, iboot, data, userdata, log, logdata, oradata number###: triple-digit format NFS volume name example: myapp_prd_data001 NFS volume full path example: /vol/myapp_prd_data001

/vol/<volume_name>/<qtree_name> Volume_name: storage controller volume name qtree_name: qtree name for single host export qtree_name=HOSTNAME or SID qtree name example: myhost qtree full path example: /vol/myapp_prd_data001/myhost qtree_name: qtree name for multiple host export qtree_name=DATATYPE$ qtree name example: binaries qtree full path example: /vol/myapp_prd_data001/binaries Use of qtrees is optional

Note: NFS export

/vol/<volume_name> or /vol/<volume_name>/<qtree_name> Volume_name: storage controller volume name to be exported Example: /vol/myapp_prd_data001 qtree_name: qtree subdirectory to be exported with NFS (optional) Example: /vol/myapp_prd_data001/binaries

CIFS application

<application>_<environment>_<datatype><number###> application: application or instance name environment: prd, stg, trn, qa, dev, sbx datatype: data, home number###: triple-digit format CIFS volume name example: mywinapp_dev_data001 CIFS volume full path example: /vol/mywinapp_dev_data001

CIFS application data qtree

/vol/<volume_name>/<qtree_name> Volume_name: storage controller volume name qtree_name: qtree name for single host share

Operational Best Practice Naming Convention

qtree_name=HOSTNAME CIFS share qtree name example: myhost qtree full path example: /vol/myapp_prd_data001/myhost qtree_name: qtree name for multiple host share qtree_name=DATATYPE qtree name example: binaries qtree full path example: /vol/my_prd_data001/binaries

\\<filername>\<share_name> Filername: CIFS server name expressed in WINS, DNS, or IP address form Share_name: path name of existing folder, qtree, or volume to be shared Share naming conventions for Data ONTAP are the same as for Windows. For example, share names ending with the $ character are hidden shares, and certain share names, such as ADMIN$ and IPC$, are reserved.

Note:

LUN name for VMFS and NFS in a virtual environment LUN name for RDMs

The LUN name for Virtual Machine File System (VMFS) and NFS FlexVol volumes should match the name of the datastore The LUN name for raw device mapping should include both the hostname and volume label or name Example: prod_hr_001_datavol010

Database data volume Microsoft applications (SQL Server, SharePoint, and Exchange) Database data LUN Database log volume Database log LUN SystemDB volume SystemDB LUN SnapInfo volume SnapInfo LUN System ID (sid) Database volume Oracle Database LUN Redo logs volume

Similar to other application information and application data, the MS Applications volumes and LUNs name should provide the following: <application>_<environment>_<datatype>_<number###> application: application or instance name environment: prd, stg, tst, qa, trn, dev, sbx datatype: data, logs, bin, tmp, data, mail number###: triple-digit format

Example: volume: EXCH_Prd_MBX_DB_001 LUN: /vol/ EXCH_Prd_MBX_DB_001/ EXCH_prd_mbx_db_001.lun

Similar to other application information and application data, the Oracle volumes and LUNs name should provide the following: <application>_<environment>_<datatype>_<db_version>_<num ber###> application: application or instance name environment: prd, stg, tst, qa, trn, dev, sbx

Operational Best Practice Naming Convention

Redo logs LUN Archive logs volume Archive logs LUN Flashback volume Flashback LUN Exports volume Admin volume qtree (NFS) Product volume and qtree (NFS) Admin volume and LUN (SAN) Product volume and LUN (SAN) TNS, OraInventory, dbaTools, and user home volume TNS, OraInventory, dbaTools, and user home LUN Client product volume and qtree (NFS) Client product volume and LUN (SAN) Logical interface (LIF): clustered Data ONTAP NAS LIFs

datatype: data, logs, fra, bin, tmp, redo, crs db_version: 10g, 11g number###: triple-digit format

Example: volume: resorcebi_prd_vol_crs_11g_001 LUN: /vol/ resorcebi_prd_vol_crs_11g_001/ resorcebi_prd_crs_11g_001.lun

<vserver_name>-<port_speed>-nas1 <vserver_name>-[nfs | cifs]1 <vserver_name>-nas1 <vserver>-data1

SAN LIFs

<vserver_name> <vserver_name>-iscsi-<node_name> <vserver_name>-fcp-<node_name> <vserver_name>-fcoe-<node_name>

Failover group LIFs

Cluster-mgmt

Operational Best Practice Naming Convention

<cluster_name>-mgmt / <cluster_name>-mgt cluster-mgmt - management Node-mgmt <node_name>-mgmt / <node_name>-mgt node-mgmt - nm-nodename vserver-mgmt <vserver_name>-mgmt / <vserver_name>-mgt vsadmin-mgmt - management or vs-mgmt-vs0 intercluster <node_name>-ic1 and <name_name>-ic2

Failover groups

Vlan: by vlan'ed port: a0a-101 could be something like vlan101 or v101 Vserver model: vs0, vs1 gen or system type oracle vmware

Operational Best Practice Naming Convention

Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact product and feature versions described in this document are supported for your specific environment. The NetApp IMT defines the product components and versions that can be used to construct configurations that are supported by NetApp. Specific results depend on each customer's installation in accordance with published specifications.

NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customers responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.

10

2013 NetApp, Inc. All rights reserved. No portions of this document may be reproduced without prior written consent of NetApp, Inc. Specifications is subject to change without notice. NetApp, the NetApp logo, Go further, faster, Data ONTAP, FlexVol, and vFiler are trademarks or registered trademarks of NetApp, Inc. in the United States and/or other countries. Microsoft, SharePoint, SQL Server, and Windows are registered trademarks of Microsoft Corporation. Linux is a registered trademark of LInus Torvalds. Oracle Operational Best Practice Naming Convention is a registered trademark of Oracle Corporation. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such. TR-4158-0413