Transcription
Veritas Disaster RecoveryAdvisor DeploymentRequirementsAIX, HP-UX, Linux, Solaris, Windows Server5.2.1
2Veritas Disaster Recovery Advisor DeploymentRequirementsLegal NoticeCopyright 2010 Symantec Corporation. All rights reserved.Product version: 5.2.1Document version: 5.2.1.0Symantec, the Symantec Logo, Veritas and Veritas Storage Foundation aretrademarks or registered trademarks of Symantec Corporation or its affiliates inthe U.S. and other countries. Other names may be trademarks of their respectiveowners.The product described in this document is distributed under licenses restrictingits use, copying, distribution, and decompilation/reverse engineering. No part ofthis document may be reproduced in any form by any means without priorwritten authorization of Symantec Corporation and its licensors, if any.THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIEDCONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANYIMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THEEXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL ORCONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING,PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATIONCONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUTNOTICE.The Licensed Software and Documentation are deemed to be commercialcomputer software as defined in FAR 12.212 and subject to restricted rights asdefined in FAR Section 52.227-19 "Commercial Computer Software - RestrictedRights" and DFARS 227.7202, "Rights in Commercial Computer Software orCommercial Computer Software Documentation", as applicable, and anysuccessor regulations. Any use, modification, reproduction release,performance, display or disclosure of the Licensed Software and Documentationby the U.S. Government shall be solely in accordance with the terms of thisAgreement.Symantec Corporation350 Ellis StreetMountain View, CA 94043http://www.symantec.com
3Technical SupportSymantec Technical Support maintains support centers globally. TechnicalSupport’s primary role is to respond to specific queries about product featuresand functionality. The Technical Support group also creates content for ouronline Knowledge Base. The Technical Support group works collaboratively withthe other functional areas within Symantec to answer your questions in a timelyfashion. For example, the Technical Support group works with ProductEngineering and Symantec Security Response to provide alerting services andvirus definition updates.Symantec’s maintenance offerings include the following: A range of support options that give you the flexibility to select the rightamount of service for any size organization Telephone and Web-based support that provides rapid response andup-to-the-minute information Upgrade assurance that delivers automatic software upgrade protection Global support that is available 24 hours a day, 7 days a weekAdvanced features, including Account Management ServicesFor information about Symantec’s Maintenance Programs, you can visit ourWeb site at the following URL:www.symantec.com/techsupp Contacting Technical SupportCustomers with a current maintenance agreement may access TechnicalSupport information at the following tance care.jspBefore contacting Technical Support, make sure you have satisfied the systemrequirements that are listed in your product documentation. Also, you should beat the computer on which the problem occurred, in case it is necessary toreplicate the problem.When you contact Technical Support, please have the following informationavailable: Product release level Hardware information Available memory, disk space, and NIC information Operating system Version and patch level Network topology Router, gateway, and IP address information Problem description:
4 Error messages and log filesTroubleshooting that was performed before contacting SymantecRecent software configuration changes and network changesLicensing and registrationIf your Symantec product requires registration or a license key, access ourtechnical support Web page at the following URL:www.symantec.com/techsuppCustomer serviceCustomer service information is available at the following URL:www.symantec.com/techsuppCustomer Service is available to assist with the following types of issues: Questions regarding product licensing or serialization Product registration updates, such as address or name changes General product information (features, language availability, local dealers) Latest information about product updates and upgrades Information about upgrade assurance and maintenance contracts Information about the Symantec Buying Programs Advice about Symantec's technical support options Nontechnical presales questions Issues that are related to CD-ROMs or manualsDocumentation feedbackYour feedback on product documentation is important to us. Send suggestionsfor improvements and reports on errors or omissions tostorage management docs@symantec.com.Include the title and document version (located on the second page), and chapterand section titles of the text on which you are reporting.
5Maintenance agreement resourcesIf you want to contact Symantec regarding an existing maintenance agreement,please contact the maintenance agreement administration team for your regionas follows:Asia-Pacific and Japancustomercare apac@symantec.comEurope, Middle-East, and Africasemea@symantec.comNorth America and Latin Americasupportsolutions@symantec.comAdditional enterprise servicesSymantec offers a comprehensive set of services that allow you to maximizeyour investment in Symantec products and to develop your knowledge,expertise, and global insight, which enable you to manage your business risksproactively.Enterprise services that are available include the following:Symantec Early Warning Solutions These solutions provide early warning of cyber attacks,comprehensive threat analysis, and countermeasures to preventattacks before they occur.Managed Security ServicesThese services remove the burden of managing and monitoringsecurity devices and events, ensuring rapid response to realthreats.Consulting ServicesSymantec Consulting Services provide on-site technicalexpertise from Symantec and its trusted partners. SymantecConsulting Services offer a variety of prepackaged andcustomizable options that include assessment, design,implementation, monitoring, and management capabilities. Eachis focused on establishing and maintaining the integrity andavailability of your IT resources.Educational ServicesEducational Services provide a full array of technical training,security education, security certification, and awarenesscommunication programs.To access more information about Enterprise services, please visit our Web siteat the following URL:www.symantec.comSelect your country or language from the site index.
6
ContentsAbout this documentIntended audience . 9Chapter 1DRA deployment architectureDeployment environment . 12DRA server . 13Oracle environment and licensing . 13Web client requirements . 13Credentials and collection methods used . 14About setting up DRA user profiles . 15About privilege control software . 15Data collection from EMC Control Center . 16Data collection from SYMCLI through a UNIX proxy . 16Data collection from NaviCLI through a UNIX proxy . 18Data collection from HDS HiCommand . 20Data collection from NetApp . 20Data collection from VMware vCenter . 21Data collection from UNIX hosts . 22Privileged commands on AIX . 27Data collection from Windows . 29Data collection from databases . 31Mail server configuration . 37Network and other environmental recommendations . 37Appendix AMethods for secure privilege provisioningsudo on UNIX hosts . 39Solaris . 40HP-UX . 40Linux . 41AIX . 41UNIX Privilege Manager . 42Suggested Oracle grant provisioning . 43Granting dictionary select privileges (recommended) . 44Granting individual view select privileges . 44Suggested MS SQL Server grant provisioning . 46
8 ContentsCommands used to collect data from NetApp . 54Queries used to scan EMC ECC . 56Configuring DRA for ECC scanning over JDBC SSL (Oracle) . 56Configuring an SSL policy . 57Copying the wallet file from the ECC Repository server . 59
About this documentThis document summarizes Veritas Disaster Recovery Advisor (DRA)deployment requirements. It contains the following chapter and appendix: Chapter 1, “DRA deployment architecture” describes the deploymentarchitecture for DRA. Appendix A, “Methods for secure privilege provisioning” describessuggested methods for secure privilege provisioning for the various entitiessupported by DRA.Intended audienceThis document is intended for the following: Project managers, who must understand DRA deployment requirements Security personnel, who need to know how DRA interacts with theirenvironment and how it should adapt to their existing security standards System administrators and database administrators, who need to know theuser account and credential settings required to support DRA
10Intended audience
ChapterDRA deploymentarchitectureThis chapter includes the following topics: “Deployment environment” on page 12 “DRA server” on page 13 “Oracle environment and licensing” on page 13 “Web client requirements” on page 13 “Credentials and collection methods used” on page 141
12 DRA deployment architectureDeployment environmentDeployment environmentAs shown in the illustration below, you install DRA on a dedicated server:The DRA deployment environment consists of the following: A dedicated DRA application server (item 1 in the illustration). A dedicated Oracle 10g repository to store the collected and analyzeddata (2).By default, you should install the Oracle repository on the DRA applicationserver. Various IT sources (3-8) that DRA collects data from for daily risk analysis. A Web interface to use and manage DRA (9).
DRA deployment architectureDRA serverDRA serverDRA must run on a dedicated host, also referred to as the DRA applicationserver. The host size depends on several parameters, including the size of yourscanned environment and how much data you need to retain. Small to mid-sizeenvironments (typically, up to 100 scanned hosts) may be able to use a VMwarehost.The recommended server configuration is as follows: Two CPUs/cores: Intel/AMD 4 GB RAM Operating system: Windows Server 2003 Standard Edition 32 bit 100 GB free disk spaceDRA requires Administrator rights on the DRA application server.Oracle environment and licensingDRA uses an Oracle 10g database to store and analyze the data collected fromthe scanned environment, also known as the DRA repository. Before you installDRA, you must install and configure the Oracle database.To obtain an Oracle 10g 30-day trial license, go to:http://edelivery.oracle.comFor a longer trial period or to install DRA permanently, you need an Oracle 10gstandard edition license. To obtain an Oracle 10g standard edition license,contact Oracle.Symantec can install the Oracle software on your designated DRA server.DRA requires full DBA rights on the DRA repository.No further maintenance is required for the Oracle database. DRA sets up andmanages the Oracle database. It creates the required schema, handles routinedatabase housekeeping, upgrades, tuning, and so on.Web client requirementsDRA has a Web-based user interface. You need Internet Explorer 6 and above,with Java client 1.5 or above. HTTP IP access from the client to the DRAapplication server should be available. The default connection port is 8080,which you may change if needed.13
14 DRA deployment architectureCredentials and collection methods usedCredentials and collection methods usedDRA mainly collects data from storage arrays, servers, and databases. For thisreason, you need to set up certain dedicated user account profiles, or specifycertain existing account profiles for the application's use.Additional data that DRA collects from other logical IT elements, such asclustering software, Logical Volume Management (LVM) software, networkservices, and so on, does not require further account provisioning. It can beretrieved through the operating system account profiles.All query methods used by DRA using these account profiles have the followingdesign principles: DRA collects data in read-only mode; it does not change your configuration. DRA only retrieves configuration data (metadata) – never actual productioncontent. For example, DRA may read database startup files to learn how adatabase instance is configured. It may also connect to the database andissue system configuration queries to determine which files store databasecontent. However, it does not query any production information, tablespacecontent, and so on. All queries use standard, well-known interfaces and commands. Nothing ishacked or retrieved in a non-standard way. In fact, all queries andcommands used are well-known to the IT staff, who often use the samequeries and commands during routine maintenance. None of the queries or commands put a noticeable load on servers, storagearrays, databases, or the network. The only significant computation isperformed on the DRA application server and the DRA Oracle repository,which are dedicated computing resources.You must enter the credential information into the DRA application, where it iskept strongly-encrypted using AES with a unique, per-customer encryption key.DRA's flexible architecture lets it adapt to your specific customer securityneeds, and it complies with a wide array of security policies and doctrines. DRAhas successfully adapted to the strictest security standards of many financial,government, and commercial organizations.The following sections describe specific credential requirements and rights foreach environment, and outline possible security adaptations. Note that yourenvironment may not use all the components mentioned here. You may ignorethose requirements.
DRA deployment architectureCredentials and collection methods usedAbout setting up DRA user profilesWhen you set up a DRA user profile, keep in mind the following: All user account profiles provisioned for the use of DRA must have apassword that does not need resetting after the first use. It is strongly recommended that you provision Tomcat user profiles withnon-expiring passwords. If that is not possible, allow the longest possiblepassword expiration period. Symantec recommends at least six months.DRA uses the provisioned account profiles noninteractively, and the defaultconnection method does not involve any plain-text password exchange.Therefore, these account profiles pose significantly lower risk thanstandard ones. Replacing the passwords on all hosts on the environmentpresents an administrative overhead that should be balanced against thislow risk.Finally, as long as expired passwords are not reset, DRA cannot detect risksin the environment. This should also be considered in favor of usingnon-expiring passwords, or ones with a long expiration period. It is strongly recommended to use the same user ID on many of the hostsand databases. The best practice is that you use the user ID drauser for alloperating system and database account profiles. The user default shell should be sh.About privilege control softwareDRA mainly uses non-privileged queries and commands that do not require anyadministrative rights. There is a small number of read-only queries andcommands that do require root privileges on UNIX. For these, Symantecrecommends using privilege control software, such as sudo, PowerBroker(pbrun), UPM (pmrun), super, and others.For sudo, the suggested syntax for each UNIX platform is described inAppendix A, “Methods for secure privilege provisioning” on page 39.You can adapt this syntax any other privilege control software.Important: Configure sudo, PowerBroker (pbrun), UPM (pmrun), and similarprivilege control software so a password is not required when executingprivileged commands.15
16 DRA deployment architectureCredentials and collection methods usedData collection from EMC Control CenterData collection is based on opening a JDBC connection to the EMC ControlCenter(ECC) repository (StorageScope sts view). The ECC repository and Storage Scopemust be installed on the same server.Read-only select queries are used to obtain data.Note: For a list of read-only queries, see Appendix A, “Methods for secureprivilege provisioning” on page 39.When you set up data collection, do the following: Provide the name or IP address of each ECC Repository server used in thescanned environment. Provide the user/password for the ECC Repository RAMBDB. The defaultaccount is stsview/sts. Make sure that IP connectivity through JDBC is available between the DRAapplication server and each ECC repository server. The default port is 1521.Data collection from SYMCLI through a UNIX proxyDRA uses the standard SYMAPI interface and read-only SYMCLI commands tocollect additional data from EMC Symmetrix arrays. The commands are run onone or more UNIX servers in the IT environment. Collectively, these servers canquery all Symmetrix arrays in the scope. These servers are also known asSYMCLI proxies.When you select SYMCLI proxies, use the following best practices: Use IT administrative servers rather than production servers. Use fewer proxies. For example, if one host can query all arrays on all sites,use it as a proxy rather than using two or more hosts. Use proxies that are consistently up and available, rather than ones that aresometimes down or unreachable.As a standard, DRA opens an SSH session to the proxy, as it does to collect datafrom any UNIX host. Similarly, it requires sudo, PowerBroker (pbrun), UPM(pmrun), or similar software to run privileged commands.For more information, see “Data collection from UNIX hosts” on page 22.
DRA deployment architectureCredentials and collection methods usedDRA uses the following privileged, read-only SYMCLI commands: /usr/symcli/bin/symcfg list /usr/symcli/bin/symdev list /usr/symcli/bin/symdisk list /usr/symcli/bin/symdg list /usr/symcli/bin/symcg list /usr/symcli/bin/symaudit list /usr/symcli/bin/syminq /usr/symcli/bin/symcli -defWhen you work with proxies, you should do the following: Provide each SYMCLI proxy name or IP address. Provide a user account profile on each SYMCLI proxy (existing or specificallycreated for DRA). This is the same as any UNIX host from the same vendor.For more information, see “Data collection from UNIX hosts” on page 22. If you prefer, provide sudo, PowerBroker (pbrun), UPM (pmrun), or similardefinitions on each SYMCLI proxy. This is the same as any UNIX host fromthe same vendor.For more information, see “Data collection from UNIX hosts” on page 22. Make sure that IP connectivity through SSH is available between the DRAapplication server and each SYMCLI proxy. The default port is 22.Important: Do not configure the same Symmetrix array to be scanned by morethan one probe, because it may cause unpredictable results.Note: By default, DRA connects to the proxies using SSH with user/passwordauthentication. If you prefer, you can use Telnet; however, it is considered lesssecure than SSH. In terms of security provisioning, the only difference in usingTelnet is that the default port is port 23, instead of the SSH port.For suggestions on appropriate sudo definitions, see Appendix A, “Methods forsecure privilege provisioning” on page 39.You can adapt these suggestions to any other similar privilege controlmechanism, such as PowerBroker.17
18 DRA deployment architectureCredentials and collection methods usedData collection from NaviCLI through a UNIX proxyDRA uses read-only NaviSECCLI commands to collect additional data from EMCCLARiiON arrays. These commands run on one or more UNIX servers in the ITenvironment. Collectively, these servers can query all CLARiiON arrays in thescope. These servers are also known as NaviCLI proxies.When you select NaviCLI proxies, use the following best practices: Use IT administrative servers rather than production servers. Use fewer proxies. For example, if one host can query all arrays on all sites,use it as a proxy rather than using two or more hosts. Use proxies that are consistently up and available, rather than ones that aresometimes down or unreachable. Use proxies that can access both Storage Processors (SPs) on CLARiiONarrays.As a standard, DRA opens an SSH session to the proxy in the same way that itdoes to collect data from any UNIX host.The connection from the proxy to the CLARiiON array requires authorizationdetails (user/password/scope) for the array or for the host and user, which havealready declared automatic (read-only) authorization for the array.You can use sudo (or similar) software to achieve already declared authorizationfor the array. For more information, see “Data collection from UNIX hosts” onpage 22.DRA uses the following privileged, read-only NaviCLI commands. For AIX, thepath is /usr/lpp/NAVICLI/. /opt/Navisphere/bin/naviseccli -np -port port -v authorization -h array IP/name getall /opt/Navisphere/bin/naviseccli -np -port port authorization -h arrayIP/name metalun -list /opt/Navisphere/bin/naviseccli -np -port port authorization -h arrayIP/name mirror -async -listgroups /opt/Navisphere/bin/naviseccli -np -port port authorization -h arrayIP/name mirror -async -list /opt/Navisphere/bin/naviseccli -np -port port authorization -h arrayIP/name mirror -sync -listgroups /opt/Navisphere/bin/naviseccli -np -port port authorization -h arrayIP/name mirror -sync -list
DRA deployment architectureCredentials and collection methods used /opt/Navisphere/bin/naviseccli -np -port port -v authorization -h array IP/name snapview -listclonefeature /opt/Navisphere/bin/naviseccli -np -port port -v authorization -h array IP/name snapview –listclonegroup /opt/Navisphere/bin/naviseccli -np -port port -v authorization -h array IP/name getlog /opt/Navisphere/bin/naviseccli -np -port port -v authorization -h array IP/name sancopy -settings -listWhere:portThe port used for CLARiiON access. The default is 443.authorizationEmpty for already declared automatic authorization.Otherwise, use the following format:-User user -Password password -Scope scope Where:array IP/name User The user name to be used for CLARiiONauthorization. Password The password to be used for CLARiiONauthorization. Scope The scope to be used for CLARiiONauthorization, represented as a numeric value (0: Global,1: Local and 2: LDAP).The array DNS name or IP address of one of the CLARiiONSPs.You should provide the following information for each NaviCLI proxy: Name or IP address A user account profile (existing or specifically created for DRA)You should provide the following information for each CLARiiON array: A user account profile (existing or specifically created for DRA). A profilewith an empty password indicates that already declared automaticauthorization is in use.You should also verify that: IP connectivity through SSH (default is port 22) is available between theDRA application server and each NaviCLI proxy. IP connectivity is available between the NaviCLI proxy and each CLARiiONarray that it scans.19
20 DRA deployment architectureCredentials and collection methods usedImportant: Do not configure the same CLARiiON array to be scanned by morethan one probe (even if the storage processors are different). This configurationmay cause unpredictable results.Note: By default, DRA connects to the proxies using SSH with user/passwordauthentication. If you prefer, you can use Telnet; however, it is considered lesssecure than SSH. In terms of security provisioning, the only difference in usingTelnet is that the default port is port 23, instead of the SSH port.For suggestions regarding appropriate sudo definitions, seeAppendix A, “Methods for secure privilege provisioning” on page 39.You can adapt these suggestions to any other similar privilege controlmechanism, such as PowerBroker.Data collection from HDS HiCommandDRA collects data from Hitachi Data Systems (HDS) arrays by opening an HTTPconnection to the HiCommand server, or servers, if more than one is used.DRA collects data using the following read-only requests: GetServerInfo GetStorageArray GetHostTo make sure that data collection goes smoothly, do the following: Provide each HiCommand server name or IP address. Provide the HiCommand Web application user name and password. Make sure that IP connectivity through HTTP (port 2001) is availablebetween the DRA application server and each HiCommand server.Data collection from NetAppDRA collects data from NetApp storage arrays (also known as Filers) byconnecting to them using SSH and issuing read-only commands. Thesecommands do not require any particular configuration. For Filers that do notsupport SSH, Telnet is used.For a list of the commands used, see “Commands used to collect data fromNetApp” on page 54.
DRA deployment architectureCredentials and collection methods usedTo make sure that data collection goes smoothly, do the following: Provide the name or IP address of each NetApp Filer in the scope. Provide each user account profile on each Filer (existing or specificallycreated for DRA). Make sure that IP connectivity through the selected protocol is availablebetween the DRA application server and each Filer. The default SSH port is22. The default Telnet port is 23.Data collection from VMware vCenterDRA collects data from vCenter using the VMware's vi API by connecting to thevCenter server, or servers, if more than one is used.DRA collects data by running read-only inquiries on the following entities: Data centers Data stores Host systems Virtual machines ClustersTo make sure that data collection goes smoothly, do the following: Provide each vCenter server name or IP address. Provide the vCenter user name and password. Make sure that IP connectivity through HTTPS (port 443) is availablebetween the DRA application server and each vCenter server.21
22 DRA deployment architectureCredentials and colle
This document summarizes Veritas Disaster Recovery Advisor (DRA) deployment requirements. It contains the following chapter and appendix: Chapter 1, “DRA deployment architecture” describes the deployment architecture for DRA. Appendix
