f5 big-ip: workload migration from traditional … traditional network typically is designed with...
TRANSCRIPT
© 2015 Cisco | F5. All rights reserved. Page 1
F5 BIG-IP: Workload Migration from Traditional Networks to Cisco
Application Centric Infrastructure Building Architectures to Solve Business Problems
Design Guide
© 2015 Cisco | F5. All rights reserved. Page 2
Contents
Solution Overview ....................................................................................................................................... 3
Migration Using F5 BIG-IP Local Traffic Manager ................................................................................... 4
Prerequisites and Network Design ............................................................................................................ 5
Configuring the Networks for Migration ................................................................................................... 6 Setting Up an External Layer 2 Endpoint Group in Cisco ACI ................................................................. 7 Configuring a Pair of F5 BIG-IP Systems in Cisco ACI ............................................................................ 8 Choosing the Level of Integration ............................................................................................................. 8
Application Migration Using the Device Package for Full Integration of Cisco ACI ............................ 8 Integrating the Device Package ................................................................................................................ 9 Steps for Full Application Migration ........................................................................................................ 13
Application Migration: BIG-IP with EPGs Only ...................................................................................... 17
Pointing Clients Directly to the Cisco ACI Virtual IP Address ............................................................. 17
Conclusion ................................................................................................................................................. 18
For More Information ................................................................................................................................ 18
© 2015 Cisco | F5. All rights reserved. Page 3
Solution Overview
Most businesses depend on their applications, and application availability has become mission critical. As various
parts of the network and data center evolve, organizations may need to replace the underlying infrastructure to
take advantage of technology shifts and advancements.
The traditional network typically is designed with multiple layers: as either a three-tier network or a two-tier
network with collapsed access and aggregation layers or collapsed core and aggregation layers. Network
services like firewalls, load balancers, and Domain Name Service (DNS) typically are placed either on the network
core or aggregation layer or in a service chassis on the aggregation layer. Figures 1 and 2 illustrate these two
designs. This document refers generically to both designs simply as a traditional network.
Figure 1: Two-Tier Traditional Network
Figure 2: Two-Tier Traditional Network with Service Chassis
© 2015 Cisco | F5. All rights reserved. Page 4
The latest evolution of the network is to a spine-and-leaf architecture to better support the increasing east-west
traffic flow in the data center. Cisco® Application Centric Infrastructure (ACI) was developed to help provide
centralized automation and policy-based application profiles. Multiple challenges exist when refreshing the
network infrastructure and moving from one network infrastructure to another. These challenges often include
technical, business, cost, time, resource, and organizational requirements. A few common requirements include:
Transparent migration of applications from traditional network designs to Cisco ACI fabric
Continued access to Layer 4 through 7 services during migration
High availability with very few and very small maintenance windows
Little need for application and server changes (ideally, no changes)
Instant rollback capability for risk mitigation
This document focuses on the use of F5 BIG-IP Local Traffic Manager (LTM) to migrate traffic at the application
level and configuration details from the viewpoint of F5 BIG-IP. Networking configuration, architecture, router
configuration, and Cisco ACI details are mentioned but are covered in depth in other documents.
Migration Using F5 BIG-IP Local Traffic Manager
The use of F5 BIG-IP LTM for migration involves treating the older traditional network and the new ACI fabric as
parts of one large network. These two different networks can be linked together using Layer 3 routing, or they can
be connected using a Layer 2 link. A Layer 2 link allows the connected devices to remain unchanged during the
migration and has the added benefit of requiring no routing changes, updates, or convergence time. To remain
focused on the migration of applications while the network infrastructure is switched (from traditional to ACI), this
document focuses on use of a Layer 2 link.
The migration procedure is as follows:
Link the traditional network to ACI with a Layer 2 external bridge domain and stretch the required VLANs
for migration to the ACI leaf switch.
Bring up a parallel set of F5 BIG-IP LTM instances in the ACI fabric. This step includes configuration of
the F5 self IP address, device package, and VIP address, and a pool of members.
Take the VIP of the BIG-IP instance in the ACI fabric and add it as a pool member to the BIG-IP instance
in the traditional network.
Physically or virtually migrate the servers for the application from the traditional network to the ACI fabric.
Add the migrated server to the ACI virtual IP address pool.
To better understand why this migration method is well suited for the task, consider how F5 BIG-IP operates. F5
BIG-IP LTM virtualizes the physical application server to an IP address backed by a pool of addresses. The pool
of addresses is then used to load-balance client requests to multiple real servers. You can take advantage of this
virtualization and embed the F5 BIG-IP virtual server address (virtual IP address) that is in the ACI fabric in the
preexisting application virtual server pool or server farm that is in the traditional tiered network. The result is that
some client requests are sent to the VIP in the ACI fabric. Figure 3 shows the relationship between the two virtual
servers and the linkage between the two networks during the migration.
© 2015 Cisco | F5. All rights reserved. Page 5
Figure 3: Virtual Server Relationship between Three- and Two-Tier Traditional Network and Cisco ACI Fabric
This guide outlines the process and steps necessary to move applications and services from a traditional tiered
network design to the new ACI fabric infrastructure. By using this technique for application migration, you can
maintain application availability, reduce unnecessary interactions between IT teams, gain instant rollback
capabilities, and perform the work without any downtime. This migration method is also valid for migration to F5
BIG-IP devices from other load-balancing products such as the aging Cisco Application Control Engine (ACE).
Prerequisites and Network Design
To use the solution, the system must meet a few requirements and be prestaged as described here:
The existing network must be functional and have a load balancer in place. The load balancer in the
existing traditional network can be a F5 BIG-IP, or it can be some other solution such as the end-of-sale
Cisco ACE.
The ACI fabric must be configured and operational.
A Layer 2 link must be established between the two networks and the relevant VLANs stretched across
them. This requirement includes establishment of communication between devices in the same subnets
and also between the traditional and ACI networks.
A pair of F5 BIG-IP systems must be configured and ready for creation of the corresponding virtual IP
address and pool.
At least one real application server must be in the ACI fabric ready to server requests. This server can be
an existing server from the traditional network that has been moved to the ACI network.
© 2015 Cisco | F5. All rights reserved. Page 6
Table 1 lists the product versions used during validation of the solution.
Table 1: Product Versions Used for Validation
Product Version
Cisco Application Policy Infrastructure Controller (APIC) 1.0(2j)
F5 BIG-IP 5050 11.4 or later
F5 Device Package 1.1.0
Configuring the Networks for Migration
Now look at a typical traffic flow for clients accessing a set of web servers load-balanced by F5 BIG-IP.
Figure 4 depicts the original traffic communication flow in the traditional network.
Figure 4: Logical Client-Request Traffic Flow in Traditional Network
1. A client resolves the application fully qualified name (FQN) with DNS for an IP address.
2. The client sends the request to the address provided, which is the VIP in the traditional network.
3. The VIP sends the request to the server pool, and the respective server responds to the request.
After the traditional network is connected to the ACI fabric, the logical traffic flow remains the same except that
the added pool member that is the ACI virtual IP address sends traffic to the pool in ACI. Figure 5 shows this
process.
© 2015 Cisco | F5. All rights reserved. Page 7
Figure 5: Logical Client-Request Traffic Flow with Cisco ACI Network
1. A client resolves the application FQN with DNS for an IP address.
2. The client sends the request to the address provided, which is the virtual IP address in the traditional
network.
3. The VIP sends the request to the server pool, and the respective server responds to the request.
4. Any requests going to the server entry LTM#2 VIP are sent across the ACI fabric to the ACI VIP.
5. The ACI VIP sends the request to the ACI VIP pool, where a respective server then responds to the
request.
With this technique, you can gain the following benefits:
You preserve the IP addressing scheme of the servers (for example, 192.168.18.x/24).
You preserve the IP addressing scheme for public-facing network used for the virtual IP addresses (for
example, 10.168.18.x/24).
You can relocate and reuse the real application servers without any changes. Simply unplug the
traditional network link and plug into the ACI network link.
You maintain application high availability because the application is never shut down.
Setting Up an External Layer 2 Endpoint Group in Cisco ACI
Refer to the following documents for information about how to set up an external Layer 2 endpoint group (EPG)
for ACI:
Cisco ACI design guide: http://www.cisco.com/c/en/us/solutions/collateral/data-center-
virtualization/application-centric-infrastructure/white-paper-c11-731960.html
Connecting ACI to outside Layer 2 and 3 networks:
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-
infrastructure/white-paper-c07-732033.html
The goal here is to create the network topology shown earlier in Figure 5.
© 2015 Cisco | F5. All rights reserved. Page 8
Configuring a Pair of F5 BIG-IP Systems in Cisco ACI
Refer to the following documents for information about how to set up a pair of F5 BIG-IP systems:
Introduction to BIG-IP initial configuration: https://support.f5.com/kb/en-us/products/big-
ip_ltm/manuals/product/bigip-system-initial-configuration-11-6-0/1.html#conceptid
Creating a device group using the configuration utility: https://support.f5.com/kb/en-
us/solutions/public/13000/600/sol13649.html
Choosing the Level of Integration
After the F5 load balancers are up and running, you need to determine the level of integration between BIG-IP
and ACI:
You can use the F5 device package to allow ACI to manage the BIG-IP devices. This approach enables
service insertion and provides full ACI feature benefits.
You can maintain the standard management of the BIG-IP devices outside ACI using the current F5
application delivery controller (ADC) management tool set. This approach provides the capability to
enable ACI features in the future.
Application Migration Using the Device Package for Full Integration of Cisco ACI
The device package option allows services to be fully integrated into Cisco APIC, the Cisco ACI fabric controller
(Figure 6). The device package is a custom interface between APIC and BIG-IP. The device package defines the
variables and procedures needed to properly configure the system. This tight integration provides a single
management point for application services deployment and enforcement. Uniform deployment and enforcement
policies enable speedy application deployment and agility.
One point to keep in mind when using the device package is that the features you can configure in ACI for BIG-IP
depend on the features that have been exposed in the device package release.
Because the most common features are included in the device package already, this method of deployment is
common and is the focus of this document.
Supported features are listed in the release notes of the latest device package:
https://downloads.f5.com/esd/product.jsp?sw=Third-Party-Integration&pro=CiscoAPIC
© 2015 Cisco | F5. All rights reserved. Page 9
Figure 6: Device Package Option Showing Expanded Service Integration View
Integrating the Device Package
To integrate the device package, you use a service contract to send traffic to the BIG-IP LTM. This contract allows
the fabric to send the traffic to the BIG-IP device automatically in the normal flow of traffic between the EPGs
(Figure 7).
Figure 7: Detailed Service Graph
To use device package integration, follow these steps:
1. Install the F5 device package.
2. Create of the logical device cluster.
3. Add the BIG-IP systems to the device cluster as concrete devices.
4. Define the logical and physical relationships for the logical interfaces.
5. Create the service graph using BIG-IP as a function node.
6. Assign the service graph to the service contract.
© 2015 Cisco | F5. All rights reserved. Page 10
Detailed steps for configuring BIG-IP and integrating it into APIC are discussed in the following guides:
F5 and Cisco APIC quick-start guide: https://downloads.f5.com/esd/serveDownload.jsp?path=/third-party-
integration/ciscoapic/1.1.0/english/build-141/&sw=Third-Party-
Integration&pro=CiscoAPIC&ver=1.1.0&container=build-141&file=cisco-apic-quick-start.pdf
F5 device package and Cisco APIC users guide:
https://downloads.f5.com/esd/serveDownload.jsp?path=/third-party-
integration/ciscoapic/1.1.0/english/build-141/&sw=Third-Party-
Integration&pro=CiscoAPIC&ver=1.1.0&container=build-141&file=cisco-apic-users-guide.pdf
For detailed deployment steps for integrating Layer 4 through 7 service devices, such as F5 BIG-IP, into APIC,
see the following guide. Please refer to the “Configuration Parameters” section of the document for guidance on
generating XML configuration parameters for use with the F5 and ACI device package.
Cisco APIC Layer 4 through 7 services deployment guide:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/L4-
L7_Services_Deployment/guide/b_L4L7_Deploy/b_L4L7_Deploy_chapter_01000.html
After these steps are complete, BIG-IP is connected and integrated with ACI. You now have the ACI Virtual IP
(VIP) for the application and the load-balancing pool. The application EPG diagram should look similar to
Figure 8.
Figure 8: Application EPG and Contract Mapping
The security contract should be similar to that shown in Figure 9.
© 2015 Cisco | F5. All rights reserved. Page 11
Figure 9: Security Contract Relationship between Server EPG and Layer 2 External Bridge Domain EPG
The Layer 4 through 7 service graph in ACI should be similar to that shown in Figure 10.
Figure 10: Service Graph Relationships
With the new VIP and pool working, test that traffic is being handled properly. You can do this by issuing
application requests directly to this new virtual IP address in the ACI fabric. The example here uses a web server,
so you can use a simple cURL command to the VIP in ACI. Figure 11 shows the server in the ACI pool sending
out a custom message.
© 2015 Cisco | F5. All rights reserved. Page 12
Figure 11: cURL Request and Output to the Cisco ACI Virtual IP Address
To help ensure that communication is occurring between the traditional network and the ACI network, you can
perform the following additional checks:
Ping the ACI VIP from the traditional BIG-IP self IP address.
Ping the traditional VIP and ACI VIP from a client in the public-facing network.
Issue a cURL command to each virtual IP address (both traditional and ACI addresses).
Note: The APIC configures the F5 BIG-IP self IP addresses into route domains, so you must specify the proper route
domain if you send a ping from the BIG-IP system controlled by ACI.
In Figure 12, the statistics show that BIG-IP is receiving connections and that they are being distributed to the
actual servers. If all the responses are good, then you should have high confidence that all is working properly.
Figure 12: New Application Server and Two Pool Members
© 2015 Cisco | F5. All rights reserved. Page 13
Steps for Full Application Migration
All the prerequisites are now completed and tested:
The traditional virtual IP address and pool are operational.
The traditional network and the ACI network are connected.
The ACI virtual IP address and pool are operational.
The F5 and ACI device package is installed.
The next step is to begin sending traffic to the ACI VIP from the traditional network BIG-IP VIP. Proceed with the
detailed migration steps provided to transparently add the ACI VIP to the traditional VIP pool and then relocate
the servers as necessary.
1. Log into the original pool and add the ACI VIP as a pool member for the traditional network. In Figure 13,
it is called ACI-VIP.
Figure 13: Original Application Server Pool with Cisco ACI VIP
After the new virtual IP address has been added to the pool, check the monitor status. It will display only green
indicators when the monitor threshold requirements have all been satisfied. After the pool is online, confirm that
the traffic is being load-balanced to the virtual IP address by looking at the statistics. Figure 13 shows packets
and connections going to the ACI virtual IP address member at the traditional network virtual IP address.
Also check the statistics on the BIG-IP in ACI to make sure that it is properly handling traffic. Figure 14 shows the
requests reaching the virtual IP address and then being load-balanced to the local pool members that are in the
ACI fabric.
© 2015 Cisco | F5. All rights reserved. Page 14
Figure 14: Application Server Pool Receiving a Request
You now have two pools handling client requests: one pool located in the traditional network, and a second pool
located in the ACI fabric. The next step is to move the physical server or virtual machine from the original
traditional VIP address pool to the new ACI VIP address pool.
Note: The health monitor request from the original traditional BIG-IP will also be sent to the ACI VIP pool. Thus, you will see
extra connections in the statistics for the ACI VIP.
2. Go to the original pool and select a node to migrate. At the node, select either Disabled or Forced Offline
so that no new requests are sent to the node (Figure 15). When no further traffic is being sent to the
server, it can be moved.
Figure 15: Node Is in the Forced Down State
© 2015 Cisco | F5. All rights reserved. Page 15
The offline diamond of Figure 16 shows that the pool member is disabled and that no new requests will be
allowed. The zero statistics values for connections provide validation that the server can be moved without
affecting the application.
Figure 16: Node Is Down and No Requests Are Being Serviced
3. If the server is a physical server, physically move the server link to the ACI fabric. If the server is a virtual
machine, migrate it to the new virtual switch that is managed by APIC and set the appropriate network.
4. When the server has been attached to the ACI fabric, the dynamic endpoint feature will automatically add
the server to the ACI-VIP server pool. After the server is in the pool, it will be subjected to the same
health monitoring requirements before it becomes an active pool member and responds to new requests
(Figure 17).
Figure 17: Server Added and Waiting to Pass Health Monitoring Threshold
Figure 17 shows the status indicator as red because monitoring requirements have not yet been met. After a few
seconds, the status indicator will become green as for the other pool members (Figure 18).
© 2015 Cisco | F5. All rights reserved. Page 16
Figure 18: Server Up and Actively Part of the Pool
5. Repeat the process and continue moving the servers over until the BIG-IP virtual IP address is the only
entry remaining in the original pool (Figure 19).
Figure 19: Original Pool with Only the Address of the New Pool
As shown in Figure 19, the only address left in the traditional pool is the IP address of the ACI VIP address pool.
This means that all the traffic is being sent to the ACI and BIG-IP network through the traditional VIP.
The final step is to have all new requests go directly to the new ACI VIP address without having to first transit the
traditional network VIP address. This step is covered in the section “Pointing Clients Directly to Cisco ACI VIP
Address” later in this document.
© 2015 Cisco | F5. All rights reserved. Page 17
Application Migration: BIG-IP with EPGs Only
Customers who are not ready for service insertion in ACI can take advantage of the ACI network design benefits
without full integration of F5 BIG-IP. The procedure for using BIG-IP devices without device package integration is
similar to the procedure discussed in the previous section, “Application Migration Using the Device Package for
Full Integration of Cisco ACI.”
Here is a condensed version of the process:
1. Create, configure, and test a new pair of F5 BIG-IP devices, a VIP address, and the corresponding pool.
You can do this easily using device groups. See the link for creating a device group using the
configuration utility in the “For More Information” section at the end of this document.
2. Add the new VIP address (ACI VIP address) to the traditional VIP address pool for servers. This addition
expands the original pool by one pool member, which is actually the virtual IP address of the F5 BIG-IP
device that is directly connected to the ACI fabric.
3. Verify that traffic is going to the ACI VIP address and that the responses are valid and correct.
4. After you verify that the application requests are working, select a pool member from the traditional data
center pool and put it into the disabled state. This step allows all existing stateful transactions and
connections to complete gracefully.
5. When all transactions have completed, remove the member from the existing traditional pool. If the pool
member is a physical server, relocate the server. If it is a virtual machine, move the virtual machine to the
ACI fabric.
6. After the server is in the new ACI fabric, add the server to the ACI pool and enable it as a pool member.
Verify that it passes the monitor checks.
7. Verify that connections are being sent to the new pool members and that the requests are valid.
8. Repeat the process and move each application server from the old pool to the new pool.
At this point, the only address in the traditional pool is the address of the VIP address pool in ACI. This should be
the same as shown earlier in Figure 19.
The final step is to have all new requests go directly to the new BIG-IP LTM that resides in ACI. This process is
discussed in the next section.
Pointing Clients Directly to the Cisco ACI Virtual IP Address
The original VIP address in the traditional network now has only a single entry and sends all traffic to the VIP
address in ACI. To complete the migration, you now need to remove the nested VIP addresses and have clients
go directly to the ACI virtual IP address. You can accomplish this in any of three ways:
If F5 GTM is being used in the network to direct traffic to the local load balancer, update the GTM entry to
send all new requests to the new pool address. When no further requests are going to the original entry,
you can remove it.
Update the DNS entry from the traditional virtual IP address to the new ACI VIP address. Then force an
update of the DNS server entries.
Manually and simultaneously change the virtual IP addresses between the two VIP addresses and then
shut down the pool in the traditional network. This method will be disruptive, you should use it only during
a maintenance window.
© 2015 Cisco | F5. All rights reserved. Page 18
Now the original application virtual server and respective pool are no longer being used. You can verify this by
looking at the connection statistics for BIG-IP. When appropriate, you can decommission and delete the unused
VIP address and pool.
Conclusion
Cisco Application Centric Infrastructure helps address the challenges of timely application provisioning and
resource scale elasticity. To take advantage of these improvements, you need to migrate from the traditional
network infrastructure to an ACI fabric. The transparent migration of workflows, applications, and services is
greatly simplified using F5 BIG-IP application delivery controllers (ADCs). F5 ADCs help make these transitions a
reality with smooth and transparent migration so that the business can stay up and running. When this solution is
coupled with additional features in the ADC such as Global Traffic Manager (GTM) and Application Security
Manager (ASM), application reliability and security is further enhanced.
For More Information
F5 and Cisco solutions: https://f5.com/solutions/technology-alliances/cisco
F5 BIG-IP and Cisco ACI solution overview: http://www.f5.com/pdf/solution-center/cisco-aci-overview.pdf
F5 BIG-IP and Cisco ACI integration demonstration: https://www.youtube.com/watch?v=5Nw2vtid7Zs
F5 BIG-IP and Cisco ACI device package: https://downloads.f5.com/esd/product.jsp?sw=Third-Party-
Integration&pro=CiscoAPIC
Creating a device group using the configuration utility: https://support.f5.com/kb/en-
us/solutions/public/13000/600/sol13649.html
Integrating Cisco ACI with existing networks: http://www.cisco.com/c/en/us/solutions/collateral/data-
center-virtualization/application-centric-infrastructure/white-paper-c11-731860.html
Service insertion with Cisco ACI: http://www.cisco.com/c/en/us/solutions/collateral/data-center-
virtualization/application-centric-infrastructure/white-paper-c11-732493.html
Connecting Cisco ACI to outside Layer 2 and 3 networks:
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-
infrastructure/white-paper-c07-732033.html
Cisco ACI design guide: http://www.cisco.com/c/en/us/solutions/collateral/data-center-
virtualization/application-centric-infrastructure/white-paper-c11-731960.html
© 2015 Cisco | F5. All rights reserved. Page 19
© 2015 Cisco and/or its affiliates. All rights reserved. Cisco and the Cisco logo are trademarks or registered
trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to
this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective
owners. The use of the word partner does not imply a partnership relationship between Cisco and any other
company. (1110R)
F5 (NASDAQ: FFIV) provides solutions for an application world. F5 helps organizations seamlessly scale cloud,
data center, and software defined networking (SDN) deployments to successfully deliver applications to
anyone, anywhere, at any time. F5 solutions broaden the reach of IT through an open, extensible framework
and a rich partner ecosystem of leading technology and data center orchestration vendors. This approach lets
customers pursue the infrastructure model that best fits their needs over time. The world's largest businesses,
service providers, government entities, and consumer brands rely on F5 to stay ahead of cloud, security, and
mobility trends. For more information, go to f5.com.
C07-733816-00 02/15