USING BROCADE ADX LOAD BALANCER WITH EMC ATMOS

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
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 H11875
Brocade ADX Load Balancers with EMC Atmos
2
Table of Contents
Executive Summary ................................................................................................. 4
Audience ............................................................................................................................ 4
Background ........................................................................................................................ 4
Single-Site Architecture ........................................................................................... 5
Multi-Site Distributed Architecture ........................................................................... 8
Atmos Configuration .............................................................................................. 10
Brocade ADX Setup ............................................................................................... 11
Brocade ADX 1000 Series Configuration ........................................................................... 11
Reference Architecture for an Online File Sharing Use Case with EMC Syncplicity and
EMC Atmos............................................................................................................ 19
Solution Overview: Online File Sharing with Syncplicity and Atmos .................................. 19
A Multi Site Deployment ................................................................................................... 20
Atmos configuration ......................................................................................................... 22
Syncplicity virtual machine deployment ........................................................................... 24
Web load balancer self signed certificate ......................................................................... 24
Syncplicity virtual machine configuration ......................................................................... 27
EMC ATMOS and Syncplicity Solution Summary ................................................................ 28
Conclusion ............................................................................................................ 29
Appendix A ....................................................................................................................... 31
Appendix B ....................................................................................................................... 32
Brocade ADX Load Balancers with EMC Atmos
3
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
Brocade ADX Load Balancers with EMC Atmos
4
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.
Brocade ADX Load Balancers with EMC Atmos
5
Figure 1
Brocade ADX Load Balancers with EMC Atmos
6
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.
Brocade ADX Load Balancers with EMC Atmos
7
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
Brocade ADX Load Balancers with EMC Atmos
8
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.”
Brocade ADX Load Balancers with EMC Atmos
9
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
Brocade ADX Load Balancers with EMC Atmos
10
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 16384
system-max session-limit 163840
system-max ssl-concurrent-conn 16384
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
Brocade ADX Load Balancers with EMC Atmos
11
enable telnet authentication
web-management https
logging x.x.x.x
logging buffered 1000
![OPTIONAL] "no telnet server"
telnet access if desired.
![OPTIONAL] snmp-server host x.x.x.x .....
management system
![OPTIONAL] snmp-client x.x.x.x
write memory
end
reload
 IP of your syslog server / management system
 can be used to completely disable
 IP of your SNMP trap server /
 IP permitted to SNMP poll this box.
 Answer “Y” to accept the reload.
3. Configure network settings.
!---ADX1’s config ONLY--hostname ADX1
no spanning-tree
router vrrp-extended
ip route 0.0.0.0/0 10.0.0.1
server source-nat
server source-nat-ip 10.6.147.x 255.255.255.0 0.0.0.0 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 10.0.0.5 255.255.255.0
ip tcp syn-proxy in
ip vrrp-extended vrid 1
backup priority 200
advertise backup
ip address 10.0.0.4
track-port eth 2
vip-group 1
activate
exit
interface ethernet 2
port-name Atmos
route-only
ip address 192.168.20.5 255.255.255.0
ip vrrp-extended vrid 2
Brocade ADX Load Balancers with EMC Atmos
12
backup priority 200
advertise backup
ip address 192.168.20.4
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 0.0.0.0/0 10.0.0.1
server source-nat
server source-nat-ip 10.6.147.x 255.255.255.0 0.0.0.0 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 10.0.0.6 255.255.255.0
ip tcp syn-proxy in
ip vrrp-extended vrid 1
backup priority 199
advertise backup
ip address 10.0.0.4
track-port eth 2
vip-group 1
activate
exit
interface ethernet 2
port-name Atmos
route-only
ip address 192.168.20.6 255.255.255.0
ip vrrp-extended vrid 2
backup priority 199
Brocade ADX Load Balancers with EMC Atmos
13
advertise backup
ip address 192.168.20.4
track-port eth 1
activate
exit
interface ethernet 16
port-name HA
exit
Brocade ADX Load Balancers with EMC Atmos
14
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-onADX>:<password>:<format>
Example: C:\>pscp mykeypairfile.cer
admin@10.0.0.5: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@10.0.0.5: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
Brocade ADX Load Balancers with EMC Atmos
15
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 atmos01 192.168.20.11
port http
port http url "GET /index.html"
server real atmos02 192.168.20.12
port http
port http url "GET /index.html"
server real atmos03 192.168.20.13
Brocade ADX Load Balancers with EMC Atmos
16
port http
port http url "GET /index.html"
server real atmos04 192.168.20.14
port http
port http url "GET /index.html"
server real atmos05 192.168.20.15
port http
port http url "GET /index.html"
server real atmos06 192.168.20.16
port http
port http url "GET /index.html"
server real atmos07 192.168.20.17
port http
port http url "GET /index.html"
server real atmos08 192.168.20.18
port http
port http url "GET /index.html"
server virtual atmos-vip01 10.0.0.50
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 10.0.0.50
source-nat-ip 10.6.147.x
exit
Brocade ADX Load Balancers with EMC Atmos
17
Once the configuration is complete, you should see a configuration in the web GUI similar to
the following two figures.
Figure 7
Figure 8
Brocade ADX Load Balancers with EMC Atmos
18
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.
Brocade ADX Load Balancers with EMC Atmos
19
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 9000.
Brocade ADX Load Balancers with EMC Atmos
20
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 9000.
11 – 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 onPremise 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.
Brocade ADX Load Balancers with EMC Atmos
21
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
Brocade ADX Load Balancers with EMC Atmos
22
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
Brocade ADX Load Balancers with EMC Atmos
23
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>
Email Address []:<any email address>
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Brocade ADX Load Balancers with EMC Atmos
24
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
Brocade ADX Load Balancers with EMC Atmos
25
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
Brocade ADX Load Balancers with EMC Atmos
26
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
Brocade ADX Load Balancers with EMC Atmos
27
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
Brocade ADX Load Balancers with EMC Atmos
28
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
Brocade ADX Load Balancers with EMC Atmos
29
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 http://www.emc.com/atmos
Brocade ADX Load Balancers with EMC Atmos
30
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.
Brocade ADX Load Balancers with EMC Atmos
31
Appendix B
Sample ADX Configuration with a multisite GSLB configuration.
ADX1
telnet@ADX1>show config
!Using 2397 out of 5242878 bytes
!
ver 12.4.00bT403
!
server msl 2
server port 80
session-sync
tcp
server source-nat
server source-nat-ip 10.6.145.11 255.255.255.0 0.0.0.0 port-range 1
!
context default
!
!
!
server real atmos01 10.6.145.38
port http
port http url "GET /rest"
!
server real atmos02 10.6.145.39
port http
port http url "GET /rest"
!
server real atmos03 10.6.145.40
port http
port http url "GET /rest"
!
server real atmos04 10.6.145.41
port http
port http url "GET /rest"
!
!
server virtual atmos-vip01 10.6.145.35
predictor least-conn
port http sticky
bind http atmos01 http atmos02 http atmos03 http atmos04 http
!
server virtual dns 10.6.145.9
port dns
Brocade ADX Load Balancers with EMC Atmos
32
!
server virtual atmos-vip02 10.6.145.102
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 10.6.145.8
gslb site ADX2newjersey
si ADX2newjersey 10.6.147.30
gslb dns zone atmos.com
host-info www http
host-info www ip-list 10.6.145.35 10.6.147.40
host-info appname01 80
host-info appname01 443
host-info appname01 ip-list 10.6.145.35 10.6.147.40
host-info appname02 80
host-info appname02 ip-list 10.6.145.102 10.6.147.102
host-info appname02 ip-weight 10.6.145.102 100
host-info appname02 ip-weight 10.6.147.102 0
host-info appname02 gslb-policy DR-only
Brocade ADX Load Balancers with EMC Atmos
33
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 10.6.145.0 255.255.255.0 10.6.145.2
ip route 0.0.0.0 0.0.0.0 10.6.145.2
!
telnet server
username admin password .....
!
interface ethernet 1
port-name External
ip address 10.6.145.8 255.255.255.0
!
End
ADX2
telnet@ADX2>show config
!Using 2357 out of 5242878 bytes
!
ver 12.4.00bT403
!
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 10.6.147.12 255.255.255.0 0.0.0.0 port-range 1
!
context default
Brocade ADX Load Balancers with EMC Atmos
34
!
server real atmos01 10.6.147.204
port http
port http url "GET /rest"
!
server real atmos02 10.6.147.205
port http
port http url "GET /rest"
!
server real atmos03 10.6.147.206
port http
port http url "GET /rest"
!
server real atmos04 10.6.147.207
port http
port http url "GET /rest"
!
!
server virtual atmos-vip01 10.6.147.40
predictor least-conn
port http sticky
bind http atmos01 http atmos02 http atmos03 http atmos04 http
!
server virtual dns 10.6.147.5
port dns
!
server virtual atmos-vip02 10.6.147.102
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
Brocade ADX Load Balancers with EMC Atmos
35
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 10.6.145.8
gslb site ADX2newjersey
si ADX2newjersey 10.6.147.30
gslb dns zone atmos.com
host-info www http
host-info www ip-list 10.6.145.35 10.6.147.40
host-info appname01 80
host-info appname01 443
host-info appname01 ip-list 10.6.145.35 10.6.147.40
host-info appname02 80
host-info appname02 ip-list 10.6.145.102 10.6.147.102
host-info appname02 ip-weight 10.6.145.102 100
host-info appname02 ip-weight 10.6.147.102 0
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 0.0.0.0 0.0.0.0 10.6.147.1
!
telnet server
username admin password .....
!
interface ethernet 1
port-name External
ip address 10.6.147.30 255.255.255.0
!
end
Brocade ADX Load Balancers with EMC Atmos
36