USING BROCADE ADX LOAD BALANCER WITH EMC ATMOS

Transcription

1 White Paper USING BROCADE ADX LOAD BALANCER WITH EMC ATMOS Best Practices Guide and Online File Sharing Reference Architecture for EMC Syncplicity Michael Wehle, Corporate Systems Engineer, EMC Abstract This document explains how to implement and configure a Brocade ADX load balancer with EMC Atmos storage. It is intended to walk the reader through the architecture, data flow, and reference architecture for online file sharing with EMC Syncplicity. May 2013

2 Copyright 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. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. VMware is a registered trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners. Part number H

3 Table of Contents Executive Summary... 4 Audience... 4 Background... 4 Single-Site Architecture... 5 Multi-Site Distributed Architecture... 8 Atmos Configuration Brocade ADX Setup Brocade ADX 1000 Series Configuration Reference Architecture for an Online File Sharing Use Case with EMC Syncplicity and EMC Atmos Solution Overview: Online File Sharing with Syncplicity and Atmos A Multi Site Deployment Atmos configuration Syncplicity virtual machine deployment Web load balancer self signed certificate Syncplicity virtual machine configuration EMC ATMOS and Syncplicity Solution Summary Conclusion Appendix A Appendix B

4 Executive Summary This document provides information about the architectural and configuration aspects of an EMC Atmos storage system with a Brocade ADX load balancer in front of the data path. To add a real-world use case that is ideal for distributed enterprises where load balancers are common networking components, a reference architecture for Online File Sharing with EMC Syncplicity and Atmos is also included. Readers should have a basic understanding of the benefits and features of the Atmos system, including the basics of the various services within the system, and should be thinking about how to best deploy the solution in a particular environment. In addition, readers should be familiar with basic networking, as well as basic network connectivity and configuration of switches, including an Brocade ADX solution. Audience This document is intended for data center operations, network administrators, network architects, storage administrators, storage architects, and Atmos administrators. Background The convergence of several forces in Enterprise storage has given rise to the mainstream adoption of object-based or cloud storage. These forces range in complexity from serving content to mobile devices, strategic adoption of agile, as-aservice business models, to increasing reliance on access to content for geographically separated knowledge-workers. Each force presents architectural and economic cost to serve challenge for traditional SAN and NAS based storage approaches. To meet these demands, object-based cloud storage is fundamentally architected differently from SAN or NAS technologies and as such, requires a different model for storage operations. Furthermore, unlike the NFS or CIFS, LAN-based, activepassive SAN or NAS approaches, cloud storage is often API-accessible, is reliant on network services such as load balancers, and delivers an inherently distributed active-active storage architecture model. EMC Atmos Storage is inherently a web service, an object-based storage architecture, taking advantage of a REST-based API. This web services layer allows the object data to be stateless, in that it can be accessed anywhere, from any node, just by the very nature of a web services protocol. While the Atmos nodes are enabled with web services, they are usually deployed behind a load balancer. In simple terms, a load balancer is a device to distribute web services workload among multiple backend 4

5 Atmos nodes. This workload distribution can be done on a per-site or location basis, or aggregated among multiple sites on a global, geographical level. At a high level, clients connect to a Virtual IP address or VIP and the load balancer distributes the Create, Read, Update, or Delete (CRUD) requests among the backend Atmos nodes. This type of workload distribution architecture is also meant to scale linearly, both from a capacity and a performance perspective. As capacity on a per-site basis starts to get full, an administrator can simply add more backend nodes on the Atmos side, and then configure those nodes behind the Brocade ADX VIP for load distribution. The same can also be said for performance workloads. This is true by virtue of the stateless nature of the REST web services protocol. Each node is meant to process load independently of each other, while participating in an overall cluster at the same time. Single-Site Architecture The solution architecture for a single site deployment is represented by the below diagram. In this configuration, we see a single site deployment with clients accessing the Atmos cloud storage through a web-enabled application. The clients connect through a Brocade ADX High Availability (HA) configuration, which then distributes the CRUD workload among the backend Atmos nodes. 5

6 Figure 1 6

7 A more specific data flow can be found in the below diagram, as follows. Figure 2 1. Client writes data through a local application over the intranet or internet via REST Web Services. The connection can be via http/https to a Virtual IP Address (VIP) configured on the Brocade ADX load balancer. 2. The ADX units can be configured with either an active/active or active/passive high availability configuration. The architecture diagram shows an active/active configuration. Both Brocade ADX units share the same VIP associated with the Atmos nodes for the local site. The ADX unit that has a VIP with a higher priority owns the VIP. It is possible to have one ADX own a set of VIPs and another ADX own the other set of VIPs; in this way, workload can be shared by the two load balancer while providing high availability service. Upon a request for a Read or Write operation, the load balancer distributes the requests according to its defined load balancing method to the group of Atmos nodes associated with the VIP. Two of the most common distribution methods are round robin and least connections. 3. The read/write request completes in Atmos, and an acknowledgment is sent back to the load balancer. 4. The return traffic is then sent back to the client. 7

8 Multi-Site Distributed Architecture Next, we take the single site deployment and add a second site to the configuration. This effectively creates an active/active multisite deployment, all contained within a single global namespace. This can then be further scaled to N sites, all in an active/active N deployment. Below is an updated architecture diagram to accommodate multiple sites. Note that we are going to configure Global Server Load Balancing (GSLB) on the Brocade ADX load balancers; GSLB uses DNS forwarding to direct clients to the appropriate geographical location based on their IP address proximity. Figure 3 8

9 The updated multisite dataflow can be described as follows: Figure 4 1. Client sends to the Brocade ADX GSLB controller a DNS query to access an Atmos cloud storage site; the GSLB controller replies with a VIP configured on one of site ADX units; then, the client writes to the VIP data through a local application over the intranet or internet via REST web services over HTTPs. load balancer 2. The Brocade ADX load balancer HA pairs are configured with the IP addresses of the Atmos nodes as real server for the local site for HTTP. The Virtual IP address (VIP) is associated with the real server IP addresses or the Atmos nodes IP addresses.. Upon receiving a request for a Read or Write operation on the VIP, the load balancer distributes the requests according to its defined policy to Atmos nodes (In the example shown, since the client is closer to Site 1, the GSLB controller determines that the client should communicate with Site 1 ADX ). 3. The client sends a request to the ADX HA pair that is determined best. 9

10 4. The read/write request is forwarded to the Atmos nodes. 5. The read/write request completes in Atmos, and an acknowledgment is sent back to the load balancer. 6. The return traffic is then sent back to the client. Atmos Configuration To configure, we first start with the Atmos configuration. This document assumes that the Atmos system has already been installed, and is up and running. From an Atmos perspective, the first task is to configure the nodes for Web Services. To do so, log into the System Administration window, and click on Edit Tenant. For further information on how to do this, please reference the XX chapter in the Atmos Administrator s guide, available on EMC Powerlink. The next step is to add the relevant Atmos nodes to the tenant with Web Services enabled on each node. This would usually include all of the relevant nodes at each of the installed Atmos locations, or RMGs. The example below illustrates this, and shows a multisite implementation. Figure 5 10

11 Brocade ADX Setup Brocade ADX 1000 Series Configuration This section assumes that both ADX units have already been upgraded to the latest software code and rebooted, and that the user is in the enable and config terminal mode. Don t forget to write memory periodically to save your configuration changes. NOTE: In general, it is best practice to fully configure the ADX units via serial console port prior to connecting them to live production devices. At the very least, follow the configuration steps through network settings below before connecting the ADX units to your switches. Note: The below configuration is a sample configuration only, and must be edited appropriately for the specific network environment. CLI configuration: 1. Create the necessary SSH and SSL key files. (IDENTICAL on both ADX units) crypto key generate dsa crypto-ssl certificate generate default_cert write memory 2. Configure system defaults and management features. (IDENTICAL on both ADX units) system-max healthck 300 server force-delete server no-fast-bringup no server use-simple-ssl-health-check server msl 2 ip ssh scp enable server tcp-age 10 server udp-age 2 server tcp-age reset both server sym-pdu-rate 1 9 system-max l3-vlan 128 system-max tcp-buffer system-max session-limit system-max ssl-concurrent-conn multicast-hw-enable unknown-unicast-hw-enable ip tcp syn-proxy eventlog size 256 aaa authentication web-server default local aaa authentication login default local no enable aaa console username admin password... your own password enable super-user-password... configuration username... password... change default password; substitute for add a password for editing add your own unique user accounts 11

12 enable telnet authentication web-management https logging x.x.x.x IP of your syslog server / management system logging buffered 1000 [OPTIONAL] "no telnet server" can be used to completely disable telnet access if desired. [OPTIONAL] snmp-server host x.x.x.x... IP of your SNMP trap server / management system [OPTIONAL] snmp-client x.x.x.x IP permitted to SNMP poll this box. write memory end reload Answer Y to accept the reload. 3. Configure network settings. ---ADX1 s config ONLY--- hostname ADX1 no spanning-tree router vrrp-extended ip route / server source-nat server source-nat-ip x port-range 1 Pick a free address same on both ADX units vlan 10 name External by port untagged ethe 1 vlan 20 name AtmosServers by port untagged ethe 2 vlan 99 name HA by port untagged ethe 16 exit server symmetric-port ethernet 16 vlan-id 99 server symmetric-group 2 server vip-group 1 exit interface ethernet 1 port-name External route-only ip address ip tcp syn-proxy in ip vrrp-extended vrid 1 backup priority 200 advertise backup ip address track-port eth 2 vip-group 1 activate exit interface ethernet 2 port-name Atmos route-only ip address ip vrrp-extended vrid 2 12

13 backup priority 200 advertise backup ip address track-port eth 1 activate exit interface ethernet 16 port-name HA exit At this point, it is safe to connect all Ethernet cables to both ADXes. ---ADX2 s config ONLY--- hostname ADX2 no spanning-tree router vrrp-extended ip route / server source-nat server source-nat-ip x port-range 1 Pick free address same on both ADXes. vlan 10 name External by port untagged ethe 1 vlan 20 name AtmosServers by port untagged ethe 2 vlan 99 name HA by port untagged ethe 16 exit server symmetric-port ethernet 16 vlan-id 99 server symmetric-group 2 server vip-group 1 exit interface ethernet 1 port-name External route-only ip address ip tcp syn-proxy in ip vrrp-extended vrid 1 backup priority 199 advertise backup ip address track-port eth 2 vip-group 1 activate exit interface ethernet 2 port-name Atmos route-only ip address ip vrrp-extended vrid 2 backup priority

14 advertise backup ip address track-port eth 1 activate exit interface ethernet 16 port-name HA exit 14

15 4. Upload SSL key and certificate to both ADXes In order for the SSL termination functionality to work properly, you must upload your SSL keypair and certificate files. While some find the GUI easier to use for these functions, this section includes examples of how to upload your SSL keypair and certificate files using PuTTY SCP from a Windows Command Prompt CLI. To upload a key-pair to a ServerIron ADX: pscp <keypair-filename> <user>@<adx_ip>:sslkeypair:<filename-on- ADX>:<password>:<format> Example: C:\>pscp mykeypairfile.cer admin@ :sslkeypair:keyfile01:password123:pem To upload a certificate file to a ServerIron ADX: pscp <cert-file-name> <user>@<adx_ip>:sslcert:<filename-on-si>:<format> Example: C:\>pscp mycertificatefile.cer admin@ :sslcert:certfile01:password123:pem scp <source-file> <username>@<adx_ip_addr>:<filetype>:<filename>:<password>:<format> -File type: sslcert sslkeypair -File name: 25 chars for key pair, 32 chars for certificate. -Password: Only required for keypair file, 64 chars. Omit field&colon for cert files. -Format: pem pkcs12 NOTE: PKCS12 format stores keys and certificates in the same file. You must use the scp keyword sslkeypair while transferring a PKCS#12 file to the ServerIron ADX. c:\ scp./mypkcsfile.p12 admin@<ip_addr>:sslkeypair:mypkcsfile:brocade:pkcs12 15

16 Below is a GUI menu to manage keys and certificates. Figure 6 5. Configure Server Load Balancing (SLB server ) features. NOTE: These sections of the configuration are identical on both ADX units with one exception: The sym-priority value on ADX1 is 200, and on ADX2 is 199 server port 80 session-sync tcp server port 443 tcp ssl profile sslprofile01 keypair-file keyfile01 certificate-file certfile01 enable-certificate-chaining cipher-suite all-cipher-suites [Optional] allow-self-signed-cert server real atmos port http port http url "GET /index.html" server real atmos port http port http url "GET /index.html" server real atmos

17 port http port http url "GET /index.html" server real atmos port http port http url "GET /index.html" server real atmos port http port http url "GET /index.html" server real atmos port http port http url "GET /index.html" server real atmos port http port http url "GET /index.html" server real atmos port http port http url "GET /index.html" server virtual atmos-vip predictor least-conn sym-priority 200 This value is 200 on ADX1, and 199 on ADX2 port http port http sticky bind http atmos01 http atmos02 http atmos03 http atmos04 http bind http atmos05 http atmos06 http atmos07 http atmos08 http port ssl port ssl sticky port ssl ssl-terminate sslprofile01 bind ssl atmos01 http atmos02 http atmos03 http atmos04 http bind ssl atmos05 http atmos06 http atmos07 http atmos08 http server vip-group 1 vip source-nat-ip x exit 17

18 Once the configuration is complete, you should see a configuration in the web GUI similar to the following two figures. Figure 7 Figure 8 18

19 Reference Architecture for an Online File Sharing Use Case with EMC Syncplicity and EMC Atmos Solution Overview: Online File Sharing with Syncplicity and Atmos The diagram below shows the different roles of the different components in a Syncplicity on-premise deployment. Figure 9: Syncplicity on-premise deployment The configuration and authentication is done is a same way it s done in the standard Syncplicity solution. But, all the data are stored on Atmos in the Data Center of the customer. 19

20 A Multi Site Deployment The diagram below details the steps followed when a user store a file on one site, share this file with another user and this other user then open the file. Figure 10: A multi site deployment 1 The user add a file on his laptop in one of the directory synchronized by Syncplicity. The Syncplicity Cloud tells the Syncplicity agent installed on the user laptop to store this file in the Data Center and provides the fully qualified DNS name (FQDN) of the web load balancer. 2 The Syncplicity agent sends an encrypted HTTP request to the web load balancer on port 443 (SSL). 3 The web load balancer validates the SSL certificate and offload it. Then, it forwards the request to one of the Syncplicity virtual appliance on port

21 4 The Syncplicity virtual appliance sends an HTTP request to the web load balancer on port 80 (SSL could be used but is not necessary because the request is coming from and going to inside the Data Center). 5 The web load balancer forwards the request to one of the Atmos node. The file is now stored in the on-premise storage as an object. 6 A policy is defined in Atmos to create a replica on the second site of each object created by Syncplicity. The file is now protected on the second site. 7 The user creates a shareable URL for this file (a unique http link to share the file) and sends this link to another user working on the second site. 8 The other user receives the link and click on it to get the file shared by the first user. This opens his default web browser on the Syncplicity website and the user can then see the file. He clicks on this file. 9 The browser sends an encrypted HTTP request to the web load balancer on port 443 (SSL). It sends the request to the web load balancer located on the second site because the DNS has been configured to resolve the FQDN of the web load balancer by the IP of the web load balancer which is the closer to the user. 10 The web load balancer validates the SSL certificate and offload it. Then, it forwards the request to one of the Syncplicity virtual appliance on port The Syncplicity virtual appliance sends an HTTP request to the web load balancer on port. 12 The web load balancer forwards the request to one of the Atmos node. The file is now read from the on-premise storage on the second site even if it has been already stored on the first site, leveraging the unique Active-Active capability of Atmos. This demonstrates the key advantages of using Atmos as the backend of the on- Premise Syncplicity deployment. This works exactly the same way with more than 2 sites. In this case, one copy of each object could be created on each site. Even if a user needs to access a file which is not stored locally, Atmos will read the object from another site and serve it to the web load balancer. The following sections step through the remainder of an actual deployment from Atmos, the load balancers, and initial app configuration. 21

22 Atmos configuration A subtenant called Syncplicity has been created on the Atmos system to allow the Syncplicity virtual appliance to store data on Atmos. Figure 11: Syncplicity subtenant 22

23 A default policy must be associated with the Syncplicity subtenant in order to specify the protection type and the different replica which will be created every time a file will be stored by Syncplicity: Figure 12: Atmos default policy To different kind of protection are the most common in a 2 sites deployment: 2 local standard replica on the site where the object is created and another standard replica on the other site 1 GeoParity replica on each site 23

24 Syncplicity virtual machine deployment The following hardware requirements must be met: A minimum of two Virtual Machines hosted on the VMware vsphere Hypervisor 5.0 or 5.1 Each Virtual Machine is configured with 4 GB of RAM, 4 virtual cores, and a 500 GB VMDK Contact your EMC Presales Support representative for the vm image and deploy per the instructions. Web load balancer self signed certificate During a POC, it can be a challenge for the customer to provide a SSL certificate. You can generate your own self-signed certificate using the following commands: openssl genrsa -out loadbalancer.key 1024 openssl req -new -key loadbalancer.key -out loadbalancer.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [GB]:FR State or Province Name (full name) [Berkshire]:IDF Locality Name (eg, city) [Newbury]:PARIS Organization Name (eg, company) [My Company Ltd]:EMC Organizational Unit Name (eg, section) []:BRS Common Name (eg, your name or your server's hostname) []:<the FQDN of the web load balancer> Address []:<any address> Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: 24

25 openssl x509 -req -days 365 -in loadbalancer.csr -signkey loadbalancer.key -out loadbalancer.crt cat loadbalancer.key loadbalancer.crt > loadbalancer.pem The certificate must be trusted by each desktop/laptop running the Syncplicity client. On Windows 7, run the command mmc.exe and add the Certificates Snap-in: Figure 13: Importing a self signed certificate on Windows 7 Import the crt file generated previously under Trusted Root Certification Authorities -> Certificates 25

26 To avoid doing this operation on each Windows client, a GPO can be configured as follow: Figure 14: Importing a self signed certificate using a GPO Import the crt file generated previously under Trusted Root Certification Authorities 26

27 Syncplicity virtual machine configuration Edit the file /etc/syncp-storage/syncp-storage.conf as below: # the access key used to authenticate this storage endpoint with Syncplicity syncplicity.ws.accesskey: "<key provided by Syncplicity" # Syncplicity Storage syncplicity.storage.type: "atmos" # atmos configuration syncplicity.storage.atmos { host: "<web load balancer ip address>" port: "80" token: "<Atmos subtenantid/uid>" secret: "<Atmos Shared Secret>" } Restart the Syncplicity service using the following command: service syncp-storage restart 27

28 EMC ATMOS and Syncplicity Solution Summary EMC Atmos cloud architecture and capabilities enable you to efficiently store, manage, and protect globally distributed, unstructured content at scale: Multisite active/active architecture. This means as users travel from their home location to a remote site, they can retrieve content from their closest Atmos instance. This gives users fast access, and also avoids incurring WAN or cellular costs to traverse long distances back to a home location. Global namespace for non disruptive scale and location independence. This means data is highly available from any location via HTTP end to end, with an active/active architecture avoiding the delays during a failover / recovery. Multitenancy to deliver secure, shared resources. This will isolate user data in software, eliminating the need to build redundant silos of infrastructure, while also metering usage of both bandwidth and storage consumed. Atmos offers a low cost, instantly accessible tier of storage. Using Atmos flexible policy engine and Syncplicity can dramatically reduce storage tasks by automating data archiving, distribution, geographical placement and overall efficiency. EMC Syncplicity can be deployed in an Atmos private cloud or it can federate to any Atmos-powered public cloud 28

29 Conclusion EMC Atmos is a cloud storage platform that lets enterprises and service providers store, manage, and protect globally distributed, unstructured content at scale. EMC Atmos provides the essential building blocks to implement a private, public, or hybrid cloud storage environment. It is optimized to efficiently store, manage, and aggregate distributed big data across locations through a single pane of glass and a common, centralized management interface. As a core construct to any successful cloud storage technology, Atmos delivers flexible access across networks and platforms methods for traditional applications, web applications, Windows, Unix, Linux, more modern mobile devices as well as legacy applications that rely on the Centera SDK API. The net result, shown in Figure 7 allows users and applications instant access to data, in a multi-tenant, distributed environment designed to deliver Storage-as-a-Service. Figure 15 Atmos has been designed from its inception with carefully architected data protection capabilities that deliver highly distributed and highly automated resiliency mechanisms to protect against a multitude of outages and failures that can occur in a data center. As an added 29

30 optimization and differentiation from traditional RAID-based block or file technologies, the Atmos policy management engine ensures data can be managed according to business rules that drive the behavior and Service Levels of the underlying storage infrastructure thereby freeing storage administrators from the mundane tasks of data replication and failure recovery. The combined result provides storage administrators and service providers the flexibility to store infinite amounts of data using distributed storage services and low-touch automation that has been optimized for the highest availability and object durability. Atmos is a truly global and scalable storage system that meets the data protection and resiliency demands for today s object storage use cases. To learn more about the Atmos Product family, see 30

31 Appendix A Notes on ADX Configuration You can remove source-nat on the ADX; but, in this case, all servers default gateways should point to the VRRP-e VRID IP address within their respective subnet. The upstream routers/firewalls should point static routes for each internal subnet at the ADX external VRRP-e VRID IP address. Construct the VLANs using whatever level of redundancy is standard within your network. Note that these are L2-only VLANs no sub-interface IPs are required on your switches in these VLANs. An external firewall is NOT explicitly required for this solution to use public IP addresses, as the ADX can be configured with ACLs, Transaction Rate Limiting, and other DDoS protection features. All server subnets can also be configured with private IPs if desired, using Network Address Translation for any outbound traffic. In this ADX configuration example, the TCP SYN flooding mitigation feature was enabled. See the latest ADX Security Guide for more details on all of these features. 31

32 Appendix B Sample ADX Configuration with a multisite GSLB configuration. ADX1 telnet@adx1>show config Using 2397 out of bytes ver bT403 server msl 2 server port 80 session-sync tcp server source-nat server source-nat-ip port-range 1 context default server real atmos port http port http url "GET /rest" server real atmos port http port http url "GET /rest" server real atmos port http port http url "GET /rest" server real atmos port http port http url "GET /rest" server virtual atmos-vip predictor least-conn port http sticky bind http atmos01 http atmos02 http atmos03 http atmos04 http server virtual dns port dns 32

33 server virtual atmos-vip predictor least-conn port http sticky bind http atmos01 http atmos02 http atmos03 http atmos04 http gslb active-rtt-gathering gslb policy metric-order set health-check geographic num-session capacity capacity threshold 85 round-robin dns ttl 5 dns active-only hash-persist dns best-only dns override dns cache-proxy dns cname-detect gslb-host-policy DR-only metric-order set health-check weighted-ip weighted-ip no geographic use-default-location dns active-only dns best-only hash-persist hash-persist persist-rehash-disable gslb site ADX1cambridge si ADX1cambridge gslb site ADX2newjersey si ADX2newjersey gslb dns zone atmos.com host-info www http host-info www ip-list host-info appname01 80 host-info appname host-info appname01 ip-list host-info appname02 80 host-info appname02 ip-list host-info appname02 ip-weight host-info appname02 ip-weight host-info appname02 gslb-policy DR-only 33

34 vlan 1 name DEFAULT-VLAN by port vlan 10 name External by port untagged ethe 1 eventlog size 256 aaa authentication web-server default local aaa authentication login default local enable telnet authentication no enable aaa console hostname ADX1 ip route ip route telnet server username admin password... interface ethernet 1 port-name External ip address End ADX2 telnet@adx2>show config Using 2357 out of bytes ver bT403 server msl 2 server port 80 session-sync tcp server port 53 allow-recursive-search tcp keepalive disable udp 2 udp keepalive 10 2 udp l4-check-only server sym-pdu-rate 1 9 server source-nat server source-nat-ip port-range 1 context default 34

35 server real atmos port http port http url "GET /rest" server real atmos port http port http url "GET /rest" server real atmos port http port http url "GET /rest" server real atmos port http port http url "GET /rest" server virtual atmos-vip predictor least-conn port http sticky bind http atmos01 http atmos02 http atmos03 http atmos04 http server virtual dns port dns server virtual atmos-vip predictor least-conn port http sticky bind http atmos01 http atmos02 http atmos03 http atmos04 http gslb active-rtt-gathering gslb policy metric-order set health-check geographic num-session capacity capacity threshold 85 round-robin dns ttl 5 dns active-only hash-persist dns best-only dns override dns cache-proxy dns cname-detect gslb-host-policy DR-only metric-order set health-check weighted-ip 35

36 weighted-ip no geographic use-default-location dns active-only dns best-only hash-persist hash-persist persist-rehash-disable gslb site ADX1cambridge si ADX1cambridge gslb site ADX2newjersey si ADX2newjersey gslb dns zone atmos.com host-info www http host-info www ip-list host-info appname01 80 host-info appname host-info appname01 ip-list host-info appname02 80 host-info appname02 ip-list host-info appname02 ip-weight host-info appname02 ip-weight host-info appname02 gslb-policy DR-only vlan 1 name DEFAULT-VLAN by port vlan 10 name External by port untagged ethe 1 eventlog size 256 aaa authentication web-server default local aaa authentication login default local enable telnet authentication no enable aaa console hostname ADX2 ip route telnet server username admin password... interface ethernet 1 port-name External ip address end 36