Sei sulla pagina 1di 10

Seamless Migration Across

F5 BIG-IP Platforms

White Paper
by AppViewX
White Paper

Contents

Introduction 3

Common F5 BIG-IP migration scenarios 4

Enterprise migration challenges 5


Manual tracking of dependencies is cumbersome and error-prone 5
Disparate configuration and object-level mapping across versions 5
Lack of validation checks before committing the changes 5
Missing change management automation and orchestration 6

AppViewX enables seamless migration through


automation and orchestration 6

APS: A flexible solution for migration 7


Bulk migration 7
Configuration migration simplified with data modeling 8
Automated pre-validation 9
Custom-built work orders with approvals 9
Post-validation and automatic rollback 9

Conclusion 10

2
White Paper

Introduction
Todays businesses depend on their applications. The data center agility and application
delivery capabilities of an organization help define its potential to create a successful
business model. Application delivery controllers (ADCs) play a vital role in application
delivery, and many enterprises prefer F5 BIG-IP solutions to improve their application
availability, performance, and security.

As cited in the Gartner Magic Quadrant for Application Delivery Controllers report, F5
is the market share leader and has a solid and long-standing understanding of the ADC
market to address complex and customized application environments. F5 offers a
broad set of product portfolios that includes physical, virtual, and cloud deployments
to support a range of use cases for enterprises and service providers. F5 has recently
refreshed its BIG-IP appliance family to the F5 BIG-IP iSeries. In addition to massive
performance and scalability across the entire line, these programmable,
software-defined hardware platforms include features designed to simplify
private-cloud deployments and hybrid-cloud build-outs. Organizations that want to
take advantage of these technology advancements will need to migrate to the new
BIG-IP iSeries.

ADC migrations are generally complex, labor-intensive, and time-consuming. Each


individual ADC may be handling multiple applications owned by different business
units with distinct priorities. The right planning and migration methodology needs to
be in place to minimize unwanted side effects, such as downtime, data loss, and
increased costs. This paper covers common migration challenges customers encounter,
and explains how AppViewX addresses them to provide a seamless experience.

3
White Paper

Common F5 BIG-IP migration scenarios


Hardware replacement:
When the current hardware is outdated and no longer cost-effective to maintain, it mandates
migration from the old BIG-IP appliance to a new one. Hardware upgrades provide new
functionality, improve performance, and enhance the end-user experience.

Software version upgrade:


Minor BIG-IP software version upgrades are usually maintenance releases with critical bug fixes,
whereas major software version upgrades introduce new features and functionality. Progressive
version upgrades are simple and straightforward compared to skip-level version upgrades.

Resource consolidation:
Company mergers and acquisitions usually result in redundant applications and BIG-IP
resources in data centers. These resources then need to be consolidated to streamline
applications and reduce software costs for better IT ROI.

Virtualisation:
Organizations may choose to migrate their physical BIG-IP appliances to virtual instances to
gain more flexible and faster deployment, optimize resources, and lower their operational cost.

Pre-production to production:
To avoid last-minute glitches or any unplanned downtime, BIG-IP software version upgrades in
large production networks are initially staged for performance and load testing before
migrating to live production environments.

Cloud adoption:
IT and operations teams are migrating their workloads to the cloud to gain flexibility and
cost-effective, on-demand resources for handling infrequent peak loads. For development
teams, the turnaround time to provision and deliver in the cloud is significantly lower and has
minimal IT dependencies. Enterprises are migrating their existing BIG-IP appliances to the
refreshed iSeries to embrace cloud initiatives.

Cisco ACE replacement:


Cisco has left the application delivery market and Cisco ACE load-balancing products have
reached end-of-sale, forcing organizations to choose alternatives. F5 is the preferred choice for
most enterprises to meet their operational and business needs, and many have migrated or are
planning to migrate from Cisco ACE to BIG-IP products.

4
White Paper

Enterprise migration challenges


Migrating ADCs across the same vendor may sound simple, but the traditional migration
approach is cumbersome and prone to manual errors. Usually, migrations are kept on the
back burner because there is lot of planning, coordination, and risk involved. Most IT and
operations teams would prefer to run with the existing software or hardware versions until
there is a compelling business need for migration. ADC migration requirements are
different for different application teams and organizations, and the devil lies in the details.
Enterprises need a migration tool that is flexible enough to design workflows that best
meet their unique business needs.

Manual tracking of dependencies is cumbersome and error-prone


When planning the migration, the time and attention spent on dependency discovery
upfront can make or break migration success. A single server may be hosting multiple
applications, and their dependencies may be spread across the data center. Manual
tracking of such dependencies is not only cumbersome but is also time-intensive and
prone to errors. It is only after migration that a missed dependency is identified, when
something is broken.

Migrations can either be box-level or specific object-level. Migration planning and


methodology will differ, but hierarchical, object-level dependency mapping should be in
place to scope out the resources and time schedule.

Disparate configuration and object-level mapping across versions


With skip-level version migrations, the configuration syntax and the input parameters may
change, so a simple image upgrade will not help. With new functionality and
architecture-level changes, the object-level dependencies and mapping will differ. The
upgraded ADC may need to be configured again from scratch. This will call for expensive,
highly skilled professionals to handle the migration.

Lack of validation checks before committing the changes


When applications are migrated from one data center to another, the IP addresses of the
migrated ADC objects may conflict with existing application ADC objects. If the conflicts
are not resolved before committing, both existing and migrated applications will not
respond. Troubleshooting or fixing overwritten objects will be very complex and may bring
the applications down.

The application object names usually change during migration, and prefixes are added or
modified to follow the naming convention policy. Depending on the scope of migration,
the total number of objects to be addressed may increase significantly. Simple spreadsheet
tracking and updating becomes impractical and provides no way to check if the new
naming convention adheres to the organizations standards.

5
White Paper

The performance and health status of the destination ADC (physical or virtual instance) needs to
be considered before initiating the migration. If the load increases beyond the destination ADCs
capacity, its performance may be impacted post-migration.

Missing change management automation and orchestration


Migration mandates cross-functional collaboration across different application and networking
teams, but usually they work in silos. Enterprises use ITSM tools, such as BMC Remedy,
ServiceNow, or other ticketing systems, to manage infrastructure changes. Migrating a simple
virtual server with a new IP address may require multiple tickets. The order of service request
changes is also interdependent. Unless a free IP is assigned from the required pool, the actual
migration is not possible. In the worst case, if the migration needs to be rolled back, a new ticket
has to be submitted again. This complete process is manual, iterative, and time-consuming.

AppViewX enables seamless migration through


automation and orchestration
Since ADC migrations are generally complex, repetitive, labor-intensive, and time-consuming, the
process needs to be streamlined and automated to achieve a quick turnaround time. Automating
change management and orchestrating with network services like IPAM and DNS systems can
bridge the silos between the teams.

As part of the AppViewX ADC+ solution, Application Provisioning System (APS) offers a simple,
form-based front end, abstracting all the application infrastructure complications in the back end.
Built-in APS workflows automate change management by integrating with external ticketing,
IPAM, and DDI solutions with a REST API interface. The workflow system ensures that all
necessary checks are in place and that only error-free configurations are migrated. In case of
contingency, it has a provision to roll back the changes gracefully.

Source and Exit Rollback


Destination ADC List Report

Input Failure Failure

User

API Bulk Migration Source Get Destination Pre-Validate Service Change Change Post
Self-Service Configuration Free IPs Configuration Request Approval Implementation Validation
Form Report Translation

Success
IPAM ITSM Migration
Mapping

Figure 1: Automating F5 BIG-IP migration with AppViewX

6
White Paper

APS: A flexible solution for migration


Customizable forms can be designed using APS. Predefined worker scripts can be
associated with the form fields or they can also be hard-coded. For instance, the source
ADC filed can be fixed and the destination ADC filed can use a worker script to pull all the
available ADCs for migration. APS self-service forms provide the flexibility to choose a
different IP address, subnet, or naming convention for the destination objects. Different
APS forms can be created and customized according to different application team needs
for self-servicing. Role-based access-control (RBAC) defines the access to these self-service
forms for different application teams.

Bulk migration
Self-service forms can be custom-designed to either migrate one BIG-IP instance (physical
or virtual) at a time or multiple BIG-IP instances simultaneously, enabling bulk migration. In
a bulk migration scenario, a CSV or XLS file with source and destination BIG-IP details is
uploaded in a predefined format as input to the self-service form.

Figure 2: Sample self-service form for F5 BIG-IP bulk migration

7
White Paper

Configuration migration simplified with data modeling

AppViewX parses the configurations from the BIG-IP source ADC and builds an
application-level hierarchal dependency of all the corresponding objects, including virtual
servers, pools, pool members, monitors, profiles, data groups, iRules, policies, SSL
certificates, and keys. This information is stored in the database using a proprietary data
model. Whichever software version the source device is using, the database stores the
configurations and object-level details in a consistent format and in a version-agnostic way.
This simplifies configuration migration from one version to another, with different
configuration syntax or object types. Data modeling makes it easy to eitherchoose
complete box-level or specific object-level migration. AppViewXs modular platform
architecture provides the flexibility to plug in support for new BIG-IP hardware platforms or
software versions easily and quickly. AppViewX supports BIG-IP software versions v9, v10,
v11, and v12.

App
Owner Inv
e n to r y
AppViewX GUI Data Base
Con
fi g u r a ti o n
Role-Based Access Control

Security Sta
t i st i c s
Engineer
ITSM Workflow

REST API Gateway


Network
Engineer Platform
Logic
Platform Logic
DevOps

Vendor Abstraction
Exec / SOC Config Translator
Dashboards

BIG-IP BIG-IP BIG-IP


Figure 3: Database stores F5 BIG-IP device data in a version-agnostic format HW VE Cloud VE

8
White Paper

Automated pre-validation
APS generates a list of source ADC objects that need to be migrated, and their IP addresses are
validated against the destination device for any duplication. If an IP address conflict is detected,
APS talks to the IPAM system via RESTful APIs and gets a free IP. It also creates the DNS record
to map the new IP address with the migrated object name.

APS then generates the configurations for the destination object and uses the naming
convention specified in the form for creating the objects. APS automates the intensive process
of manually mapping and typing the configurations with custom parameters, saving a lot of
time and effort.

Custom-built work orders with approvals


APS checks if the performance and CPU load of the destination ADC is within the permissible
threshold level before creating an ITSM service request ticket via RESTful APIs. The service
request sends the destination devices health status and the final configurations to the
networking team for review. Upon approval, APS takes a snapshot of the current configurations
and pushes the migration-related configurations to the destination ADC. If the configurations
are applied successfully, APS generates the migration-mapping list for records. This list will have
all the details of the migrated objects and their corresponding source-object mapping.

Figure 4: Service request ready for approval

Post-validation and automatic rollback


In the APS workflow, post-validation logic checks the status of all the migrated objects. Various
checks can be performed at this stage to make sure everything is working as expected. It provides
the flexibility to either report the issue or undo the entire set of ADC changes gracefully.

9
White Paper

Conclusion
There is no silver-bullet solution for migration. ADC migration requirements are different for every
organization and for each application team within the same organization. AppViewX APS provides the
flexibility to design the workflow according to business needs. APS has helped many customers to
automate and orchestrate seamless migration to the latest versions of F5 BIG-IP. A simple, self-service
form-based approach provides the ability to define the workflows for discovering, validating, and
migrating BIG-IP objects quickly and helps organizations embrace digital transformation.

About AppViewX
AppViewX is a global leader in the management, automation and orchestration of network services in brownfield and greenfield data centers.
The AppViewX Platform helps network operations (NetOps) adapt to technology and process demands, such as agile, DevOps, IoT, cloud, and
software-defined infrastructure. AppViewX delivers greater business agility and efficiency at a lower cost.
For more information, visit www.appviewx.com.

AppViewX Inc., info@appviewx.com +1 (212) 400 7541


500 Yale Avenue North, Suite 100, Seattle, WA 98109 www.appviewx.com +44 (0) 203-514-2226

2017 AppViewX, Inc. All Rights Reserved. 10

Potrebbero piacerti anche