vcmp Systems: Configuration Version 11.4

Transcription

1 vcmp Systems: Configuration Version 11.4

2

3 Table of Contents Table of Contents Legal Notices...7 Acknowledgments...9 Chapter 1: vcmp Overview...13 vcmp overview...14 vcmp components...14 BIG-IP license considerations for vcmp...15 vcmp provisioning overview...15 vcmp best practices...16 Chapter 2: Initial vcmp Setup...19 Overview: Initial vcmp setup...20 vcmp deployment worksheet...20 Activating the BIG-IP license for a vcmp VIPRION...21 Configuring the management port and administrative user accounts...21 Provisioning the BIG-IP system for vcmp...22 Accessing the vcmp host...22 Creating trunks...22 Creating VLANs...23 Creating a vcmp guest...23 Setting a vcmp guest to the Deployed state...25 Provisioning a BIG-IP module within a guest...25 Creating a self IP for a VLAN...26 Overview: Verifying initial vcmp configuration...27 Creating a pool to process HTTP traffic...27 Creating a virtual server to manage HTTP traffic...27 Chapter 3: Create an Active-Standby Configuration...29 Overview: Creating an active-standby DSC configuration...30 About DSC configuration on a VIPRION system...30 DSC prerequisite worksheet...32 Task summary...33 Specifying an IP address for config sync...33 Specifying an IP address for connection mirroring...34 Specifying the HA capacity of a device...35 Establishing device trust...35 Creating a Sync-Failover device group...36 Syncing the BIG-IP configuration to the device group...37 Specifying IP addresses for failover communication...38 Syncing the BIG-IP configuration to the device group

4 Table of Contents Implementation result...39 Chapter 4: Understanding Clusters...41 Cluster overview...42 Viewing cluster properties...42 Cluster properties...42 Viewing cluster member properties...43 Cluster member properties...43 Enabling and disabling cluster members...44 Changing a cluster-related management IP address...44 Cluster-related IP addresses...44 Chapter 5: Understanding vcmp Hosts...47 Overview: Managing vcmp hosts...48 Viewing host properties for slots...48 vcmp host properties...48 Chapter 6: Understanding vcmp Guests...51 About vcmp guests...52 About network modes for a vcmp guest...52 Modifying the properties of a vcmp guest...53 Viewing the properties of a vcmp guest...53 Overview: Blade swap for vcmp guest...54 Disabling a vcmp guest...54 Migrating a vcmp guest...54 Migrating a single slot guest...55 Hot swapping a VIPRION blade...55 About software image selection and live installation...56 About vcmp guest states...56 About system resource allocation...57 About CPU cores allocation...57 About virtual disks allocation...58 About hardware processors allocation...58 vcmp guest modification considerations...58 Chapter 7: Working with vcmp Virtual Disks...59 Overview: Managing virtual disks...60 Detaching virtual disks from a vcmp guest...60 Viewing virtual disks not attached to a vcmp guest...60 Attaching a detached virtual disk to a vcmp guest...60 Deleting a virtual disk from the BIG-IP system...61 Chapter 8: Managing vcmp Statistics

5 Table of Contents Overview: Managing statistics...64 Viewing virtual disk statistics...64 Viewing vcmp guest statistics with the BIG-IP Configuration utility...64 Viewing disk usage statistics

6 Table of Contents 6

7 Legal Notices Publication Date This document was published on May 15, Publication Number MAN Copyright Copyright , F5 Networks, Inc. All rights reserved. F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice. Trademarks Access Policy Manager, Advanced Client Authentication, Advanced Routing, APM, Application Security Manager, ARX, AskF5, ASM, BIG-IP, BIG-IQ, Cloud Extender, CloudFucious, Cloud Manager, Clustered Multiprocessing, CMP, COHESION, Data Manager, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client, Edge Gateway, Edge Portal, ELEVATE, EM, Enterprise Manager, ENGAGE, F5, F5 [DESIGN], F5 Management Pack, F5 Networks, F5 World, Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM, GUARDIAN, IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iapps, icontrol, ihealth, iquery, irules, irules OnDemand, isession, L7 Rate Shaping, LC, Link Controller, Local Traffic Manager, LTM, Message Security Manager, MSM, OneConnect, OpenBloX, OpenBloX [DESIGN], Packet Velocity, Policy Enforcement Manager, PEM, Protocol Security Manager, PSM, Real Traffic Policy Builder, Rosetta Diameter Gateway, Scale N, Signaling Delivery Controller, SDC, SSL Acceleration, StrongBox, SuperVIP, SYN Check, TCP Express, TDR, TMOS, Traffic Management Operating System, Traffix Diameter Load Balancer, Traffix Systems, Traffix Systems (DESIGN), Transparent Data Reduction, UNITY, VAULT, VIPRION, vcmp, virtual Clustered Multiprocessing, WA, WAN Optimization Manager, WebAccelerator, WOM, and ZoneRunner, are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without F5's express written consent. All other product and company names herein may be trademarks of their respective owners.

8

9 Acknowledgments This product includes software developed by Bill Paul. This product includes software developed by Jonathan Stone. This product includes software developed by Manuel Bouyer. This product includes software developed by Paul Richards. This product includes software developed by the NetBSD Foundation, Inc. and its contributors. This product includes software developed by the Politecnico di Torino, and its contributors. This product includes software developed by the Swedish Institute of Computer Science and its contributors. This product includes software developed by the University of California, Berkeley and its contributors. This product includes software developed by the Computer Systems Engineering Group at the Lawrence Berkeley Laboratory. This product includes software developed by Christopher G. Demetriou for the NetBSD Project. This product includes software developed by Adam Glass. This product includes software developed by Christian E. Hopps. This product includes software developed by Dean Huxley. This product includes software developed by John Kohl. This product includes software developed by Paul Kranenburg. This product includes software developed by Terrence R. Lambert. This product includes software developed by Philip A. Nelson. This product includes software developed by Herb Peyerl. This product includes software developed by Jochen Pohl for the NetBSD Project. This product includes software developed by Chris Provenzano. This product includes software developed by Theo de Raadt. This product includes software developed by David Muir Sharnoff. This product includes software developed by SigmaSoft, Th. Lockert. This product includes software developed for the NetBSD Project by Jason R. Thorpe. This product includes software developed by Jason R. Thorpe for And Communications, This product includes software developed for the NetBSD Project by Frank Van der Linden. This product includes software developed for the NetBSD Project by John M. Vinopal. This product includes software developed by Christos Zoulas. This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman. This product includes software developed by Balazs Scheidler which is protected under the GNU Public License. This product includes software developed by Niels Mueller which is protected under the GNU Public License.

10 Acknowledgments In the following statement, This software refers to the Mitsumi CD-ROM driver: This software was developed by Holger Veit and Brian Moore for use with 386BSD and similar operating systems. Similar operating systems includes mainly non-profit oriented systems for research and education, including but not restricted to NetBSD, FreeBSD, Mach (by CMU). This product includes software developed by the Apache Group for use in the Apache HTTP server project ( This product includes software licensed from Richard H. Porter under the GNU Library General Public License ( 1998, Red Hat Software), This product includes the standard version of Perl software licensed under the Perl Artistic License ( 1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard version of Perl at This product includes software developed by Jared Minch. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product contains software based on oprofile, which is protected under the GNU Public License. This product includes RRDtool software developed by Tobi Oetiker ( and licensed under the GNU General Public License. This product contains software licensed from Dr. Brian Gladman under the GNU General Public License (GPL). This product includes software developed by the Apache Software Foundation ( This product includes Hypersonic SQL. This product contains software developed by the Regents of the University of California, Sun Microsystems, Inc., Scriptics Corporation, and others. This product includes software developed by the Internet Software Consortium. This product includes software developed by Nominum, Inc. ( This product contains software developed by Broadcom Corporation, which is protected under the GNU Public License. This product contains software developed by MaxMind LLC, and is protected under the GNU Lesser General Public License, as published by the Free Software Foundation. This product includes Intel QuickAssist kernel module, library, and headers software licensed under the GNU General Public License (GPL). This product includes software licensed from Gerald Combs (gerald@wireshark.org) under the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or any later version. Copyright 1998 Gerald Combs. This product includes software developed by Thomas Williams and Colin Kelley. Copyright , 1998, 2004, 2007 Permission to use, copy, and distribute this software and its documentation for any purpose with or without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Permission to modify the software is granted, but not the right to distribute the complete modified source code. Modifications are to be distributed as patches to the released version. Permission to distribute binaries produced by compiling modified sources is granted, provided you 1. distribute the corresponding source modifications from the released version in the form of a patch file along with the binaries, 10

11 vcmp Systems: Configuration 2. add special version identification to distinguish your version in addition to the base release version number, 3. provide your name and address as the primary contact for the support of your modified version, and 4. retain our contact information in regard to use of the base software. Permission to distribute the released version of the source code along with corresponding source modifications in the form of a patch file is granted with same provisions 2 through 4 for binary distributions. This software is provided "as is" without express or implied warranty to the extent permitted by applicable law. This product contains software developed by Google, Inc. Copyright 2011 Google, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 11

12

13 Chapter 1 vcmp Overview vcmp overview vcmp components BIG-IP license considerations for vcmp vcmp provisioning overview vcmp best practices

14 vcmp Overview vcmp overview Virtual Clustered Multiprocessing (vcmp) is a feature of the BIG-IP system that allows you to run multiple instances of the BIG-IP software on a single hardware platform. vcmp allocates a specific share of the hardware resources to each BIG-IP instance, or vcmp guest. Each guest you create behaves as a separate BIG-IP device, having its own CPU, memory, and disk space. Each guest also has its own configuration, log files, and kernel instance. vcmp is built on F5 Networks' CMP technology. CMP works with cluster members. Cluster members are slots within a chassis. CMP allows cluster members to work together to form a coherent, distributed traffic-processing system to share traffic load. vcmp takes this one step further by allowing you to create and run virtualized BIG-IP modules, using a standards-based, purpose-built hypervisor. Important: Before you license, provision, and configure the vcmp feature, verify that you have correctly configured the hardware platform. For more information, see the relevant platform guide and configuration guide on the F5 Networks AskF5 Knowledge Base web site, Important: The vcmp feature runs on both chassis and appliance type platforms. Discussions in this guide that reference slots and blades are not applicable to appliances. In virtually all cases, appliance-based systems can be thought of as a device with a single slot. vcmp components A vcmp system includes these main components. Term BIG-IP cluster Definition A BIG-IP cluster is the set of available slots (cluster members) on the chassis. You manage a BIG-IP cluster using the Clusters screens in the BIG-IP Configuration utility. Note: This term is not applicable for appliances. Cluster IP address A cluster IP address is a management IP address that you assign to a cluster to access the system. On a vcmp system, there are multiple cluster IP addresses: one for the BIG-IP cluster (to access the vcmp host), and one for each virtual cluster (to access each guest). Note: This term is not applicable for appliances. vcmp daemon vcmp guest This daemon, named vcmpd, performs most of the work to create and manage guests, as well as to configure the virtual network. A vcmp guest is an object that you create on the vcmp system for the purpose of running one or more BIG-IP modules. A guest consists of a TMOS instance, plus one or more BIG-IP modules. Each guest has its own share of hardware resources that the vcmp host allocates to it, effectively making each guest function like a separate BIG-IP device. 14

15 vcmp Systems: Configuration Term vcmp host Virtual cluster Definition The vcmp host is the system-wide hypervisor that makes it possible for you to create, view, and manage all guests on the system. A vcmp host allocates system resources to guests as needed. A virtual cluster is similar to a normal cluster on a chassis, except that unlike a normal cluster, a separate virtual cluster exists for each guest on the system. A virtual cluster contains only the portions of the slots that pertain to an individual guest. For example, if a guest spans two slots, then the two slot portions for the guest represent a virtual cluster. There is a one-to-one correlation of a virtual cluster to a guest. Note: This term is not applicable for appliances. Virtual disk A virtual disk is the portion of disk space on a slot that the system has allocated to a guest. For example, if a guest spans three slots, the system creates three virtual disks for that guest. Each virtual disk is implemented as an image file with an.img extension, such as guest_a.img. Virtual management network VM Note: Appliance devices have just one slot. The virtual management network contains the components necessary to connect a guest to the management network of the vcmp host. A Virtual machine is the portion of a guest that resides on a slot. For example, a guest that spans four slots comprises four VMs. Note: Appliance devices have just one slot. BIG-IP license considerations for vcmp The BIG-IP system license authorizes you to provision and run the vcmp feature. Note the following considerations: Each guest inherits the license of the vcmp host. The license must include all BIG-IP modules that are to be provisioned within the guest. Examples of BIG-IP modules are BIG-IP Local Traffic Manager and BIG-IP Global Traffic Manager. The license specifies the maximum number of vcmp guests that you can deploy simultaneously. You activate the BIG-IP system license when you initially set up the system. vcmp provisioning overview The BIG-IP system allocates a portion of its resources to running vcmp. The system also allocates various system resources to each vcmp guest that you create. You enable this allocation through various types of provisioning: First, you provision the BIG-IP system for vcmp, by logging into the system and using the Resource Provisioning screens within the BIG-IP Configuration utility. When you do this, the BIG-IP system 15

16 vcmp Overview dedicates almost all of the disk space to running the vcmp feature. (The reserved disk space protects against any possible resizing of the file system.) After creating a guest, you set the State of the guest to Provisioned, which installs the guest on the host and causes the BIG-IP system to allocate the necessary system resources (such as CPU cores and virtual disks) to the guest. Each guest takes you about 5 minutes to set up. Finally, after you deploy the guest, you provision specific BIG-IP modules within each guest, by logging into each guest and using the Resource Provisioning screens within the BIG-IP Configuration utility. In this way, each guest can run a different combination of modules. For example, one guest can run BIG-IP LTM only, while a second guest can run LTM and BIG-IP ASM. vcmp best practices F5 Networks has the following recommendations for managing a vcmp system. Category Guest configuration Recommendation If you need to move a guest's configuration to another slot, copy the guest configuration and then de-allocate all virtual resources (virtual disk, CPU cores, and so on) from the guest. Note: Guest migration is not applicable for appliance devices. Licensing Local traffic configuration Network setup Self IP address configuration vcmp provisioning Virtual disk management Before upgrading a guest to a newer version of BIG-IP software later, you might need to coordinate with the vcmp host administrator to renew the license key. When you are logged in to the vcmp host, do not configure local traffic features (virtual servers, pools, profiles, and so on). To configure local traffic features, you must be logged in to a guest using the guest's management IP address, and the BIG-IP LTM module must be provisioned. When initially setting up the BIG-IP system, physically wire each slot's management interface to an external bridge. Access to the vcmp host would otherwise be impossible, because vcmp guests can be deployed on any slot in the chassis, and the primary member for a guest's virtual cluster can migrate. When you follow this recommendation, you do not need to re-configure the vcmp host or any external networks when the primary member of a virtual cluster changes. Configure self IP addresses on the vcmp guests. Because a vcmp guest acts as a fully functional BIG-IP system, configure self IP addresses on each vcmp guest just as you would on a physical BIG-IP system. You can also configure self IP addresses on the vcmp host to facilitate basic network connectivity tests. However, these self IP addresses are not visible to vcmp guests. When you provision the vcmp feature, the BIG-IP system allocates most, but not all, of the disk space to the vcmp application volume. The system reserves disk space for other uses. When a virtual disk becomes unattached from a guest, that virtual disk remains on the system. To prevent unattached virtual disks from consuming disk space over time, consider deleting unwanted virtual disks from the system. Important: Before deciding to delete a virtual disk, make certain that there is no potential use for it. Configuration objects for guests that require that virtual disk for re-creation, will no longer be available. 16

17 vcmp Systems: Configuration Category VLAN configuration Recommendation Configure VLANs on the vcmp host instead of on the guest, because VLANs specified in the guest are not accessible on the vcmp host. 17

18

19 Chapter 2 Initial vcmp Setup Overview: Initial vcmp setup Overview: Verifying initial vcmp configuration

20 Initial vcmp Setup Overview: Initial vcmp setup Virtual Clustered Multi-Processing (vcmp) is a feature of the BIG-IP system that makes it possible for you to run multiple instances of the BIG-IP software on a single hardware platform. Using the following implementation, you can create one guest on a vcmp system, and then, within the guest, configure the basic Local Traffic Manager objects for processing HTTP application traffic: a pool, an HTTP profile, and a standard virtual server. A vcmp guest is a virtual BIG-IP device. Task summary Activating the BIG-IP license for a vcmp VIPRION Configuring the management port and administrative user accounts Provisioning the BIG-IP system for vcmp Accessing the vcmp host Creating trunks Creating VLANs Creating a vcmp guest Setting a vcmp guest to the Deployed state Provisioning a BIG-IP module within a guest Creating a self IP for a VLAN vcmp deployment worksheet There are a number of points during the vcmp deployment process at which you will need to make decisions or provide values. Use this table as a prompt for gathering the answers and values you will need, so that you can provide them when performing the vcmp initial setup. Configuration component Active slots CPU core requirements External gateway address FQDN Guest mode IP address range Link aggregation control protocol Network mask Cluster primary IP address User role Considerations How many blades are installed (and in which slots)? How many CPU cores do you want to allocate to each guest? What is the gateway address (next hop) for external traffic? What is the fully-qualified domain name (FQDN) for your BIG-IP system? Should your guests be in bridged or isolated mode? What is the IP address range that is valid for the vcmp guests you create? Do your trunks require LACP mode? What is the network mask for the guest IP? What is the cluster primary IP address? The management IP address assigned to the chassis' primary cluster during chassis installation is used to access the vcmp host. Do you have a user role of Administrator? You need to have a user role of Administrator to perform the tasks in this process. 20

21 vcmp Systems: Configuration Activating the BIG-IP license for a vcmp VIPRION To activate the vcmp license, you need access to a browser and the base registration key. The base registration key is a character string that the license server uses to verify the type and number of F5 Networks products that you are entitled to license. If you do not have a base registration key, contact the F5 Networks sales group ( You license vcmp from the License screen of the Setup Utility. 1. From a workstation attached to the network on which you configured the management interface, type the following URL syntax where <management_ip_address> is the address you configured for device management: 2. At the prompts, type the user name admin and the password admin. 3. Click Log in. The Setup Utility screen opens. 4. Click Activate. The License screen opens. 5. In the Base Registration Key field, paste your base registration key. 6. Click Next. The End User License Agreement (EULA) displays. 7. Review the EULA. When you click Accept, the Platform screen opens. Configuring the management port and administrative user accounts Configure the management port, time zone, and the administrative user names and passwords. 1. On the screen for configuring general properties, for the Management Port Configuration setting, select Manual and specify the IP address, network mask, and default gateway. 2. In the Host Name field, type a fully-qualified domain name (FQDN) for the system. The FQDN can consist of letters, numbers, and/or the characters underscore ( _ ), dash ( - ), or period (. ). 3. For the Host IP Address setting, retain the default value Use Management Port IP Address. 4. From the Time Zone list, select a time zone. The time zone you select typically reflects the location of the F5 system. 5. For the Root Account setting, type and confirm a password for the root account. The root account provides console access only. 6. For the Admin Account setting, type and confirm a password. Typing a password for the admin account causes the system to terminate the login session. When this happens, log in to the F5 Configuration utility again, using the new password. The system returns to the appropriate screen in the Setup utility. 7. For the SSH Access setting, select or clear the check box. 8. Click Next. 9. In the Standard Network Configuration area of the screen, click Next. This displays the screen for enabling configuration synchronization and high availability. 21

22 Initial vcmp Setup Overview: Initial vcmp setup Activating the BIG-IP license for a vcmp VIPRION Provisioning the BIG-IP system for vcmp Provisioning the BIG-IP system for vcmp You must activate the license and provision the vcmp feature before you can create any vcmp guests. 1. On the Main tab, click System > Resource Provisioning. 2. From the vcmp list, select Dedicated. Because you are setting up the vcmp host, not the guests, verify that all other modules are set to None. The vcmp feature must be run as a dedicated application. You license and provision the BIG-IP modules on the vcmp guests once you create them. 3. Click Update. TMOS now functions as the hypervisor for the vcmp system. Accessing the vcmp host Before you can access the vcmp host, configure the VIPRION chassis or appliance, including the management IP address. Also, you must have the Administrator user role assigned to your user account. Perform this task to access the vcmp host after you have created and configured the VIPRION chassis or appliance. Important: After you access the vcmp host, you do not create self IP addresses on the vcmp host. While self IP addresses on hypervisors are completely functional for basic traffic like ICMP (ping) and verifying that the host self IP addresses work correctly is an integral part of testing and hypervisor traffic switch verification, these self IP addresses are not visible nor useful from a guest perspective. You create self IP addresses that process guest traffic from the individual guests, because otherwise the guests could not "see" or make use of them. 1. From a system on the external network, display a browser window. 2. In the URL field, type the management IP address that you previously assigned to the chassis, as follows: The browser displays the login screen for the BIG-IP Configuration utility. Creating trunks To configure trunks for the VIPRION chassis or appliance, the four external interfaces must be cabled to your Internet gateway, external bridge, or vendor switch. The first objects you configure are trunks that tie the internal and external vendor switch interfaces to the corresponding VIPRION chassis or appliance interfaces. 1. Use a browser to log in to the management IP address of the VIPRION chassis or appliance. This logs you in to the vcmp host. 2. On the peer (vendor) switch on the external network, create a trunk that includes the four external interfaces to which you have physically connected the external interfaces of the four blades. 22

23 vcmp Systems: Configuration If the peer switch is configured to use Link Aggregation Control Protocol (LACP), you must enable LACP. 3. Create a trunk, and if the peer switch is configured to use LACP, enable LACP on the new trunk: a) On the Main tab, expand Network, and click Trunks. The Trunks screen opens. b) At the upper right corner of the screen, click Create. The New Trunk screen opens. c) Assign the name trunk_ext, and assign an external interface of blade 1 to the trunk. d) Enable LACP mode, if required. e) Click Finished. 4. Repeat the previous step, but this time, configure a trunk that ties the vendor switch internal interface to the VIPRION internal interface. Assign the name trunk_int. Creating VLANs You create VLANs and associate them with interfaces or trunks so that traffic will route to pool members in that VLAN's network space. 1. Use a browser to log in to the management IP address of the VIPRION chassis or appliance. This logs you in to the vcmp host. 2. On the Main tab, expand Network, and click VLANs. The VLANs screen opens. 3. Click Create. The New VLAN screen opens. 4. Configure a VLAN named external, and assign it to the trunk named trunk_ex as an untagged interface. 5. Click Finished. 6. Repeat steps 3 through 5, but this time, configure a VLAN named internal, and assign it to the trunk named trunk_int. 7. Repeat steps 3 through 5 one more time, but this time, configure a VLAN named HA, assign it to the trunk named trunk_int as a tagged interface. Creating a vcmp guest To create a vcmp guest, you need a VIPRION chassis or appliance configured with a management IP address, some base network objects such as trunks and VLANs, and you must license and provision the system to run the vcmp feature. You create a vcmp guest when you want to configure and run one or more BIG-IP modules as though the modules were running together on their own BIG-IP device. For example, you can create a guest that runs BIG-IP Local Traffic Manager and BIG-IP Global Traffic Manager. You specify on which slots the guest runs and how many cores you want for each guest. Note: This procedure creates a guest in Bridged mode. 23

24 Initial vcmp Setup Note: When creating a guest, if you see an error message such as Insufficient disk space on /shared/vmdisks. Need 24354M additional space., you must delete existing unattached virtual disks until you have freed up that amount of disk space. 1. Use a browser to log in to the management IP address of the VIPRION chassis or appliance. This logs you in to the vcmp host. 2. On the Main tab, click vcmp > Guest List. 3. Click Create. 4. From the Properties list, select Advanced. 5. In the Name field, type a name for the guest. 6. In the Host Name field, type the host name of the BIG-IP system. Assign a fully-qualified domain name (FQDN). If you assign a name that is not an FQDN, the system might display an error message. If you leave this field blank, the system assigns the name localhost.localdomain. 7. From the Cores Per Slots list, select the number of cores you want allocated to this guest. Tip: The number of cores allocated to a guest determines the system resources for this guest. The number you can select depends on the type of hardware you have. Important: For appliance devices, the next three steps do not apply; the corresponding user interface controls appear only on chassis devices. For appliance devices, skip to configuring the Management Network. 8. From the Number of Slots list, select the maximum number of chassis slots on which you want your guest to reside. This specifies the maximum number of slots that your guest can consume on the chassis. Note that once you configure the number of slots your guest spans, you can change this value later to suit your needs. 9. From the Minimum Number of Slots list, select the minimum number of chassis slots that must be available for this guest to deploy. Important: The minimum number of slots you specify must not exceed the maximum number of slots you specified. Important: If you are creating a guest that will deploy on a B4300 blade and you plan to provision that guest with the AM module, specify a minimum of 4 cores for this guest. 10. From the Allowed Slots List select the specific slots on which you want your guest to reside by moving the slot number to the Selected field using the Move button. Important: If you want to allow the guest to deploy onto any slots in the chassis, add them all. Bear in mind that the number of slots in the Allowed Slots list must equal or exceed the number specified in the Minimum Number of Slots list. 11. From the Management Network list, select Bridged. 12. For the IP Address setting, fill in the required information: a) In the IP Address field, type a unique management IP address that you want to assign to the guest. You use this IP address to access the guest when you want to manage a module running within the guest. b) In the Network Mask field, type the network mask for the management IP address. 24

25 vcmp Systems: Configuration c) In the Management Route field, type a gateway address for the management IP address. 13. From the Initial Image list, select an ISO image file for installing TMOS software onto the guest's virtual disk. 14. In the Virtual Disk list, retain the default value of None. The BIG-IP system creates a virtual disk with a default name (the guest name plus the string.img, such as guesta.img). Note that if an unattached virtual disk file with that default name already exists, the system displays a message, and you must manually attach the virtual disk. You can do this using the tmsh command line interface, or use the Configuration utility to view and select from a list of available unattached virtual disks. 15. For the VLAN List setting, select both an internal and an external VLAN name from the Available list, and use the Move button to move the VLAN names to the Selected list. 16. From the Requested State list, select Provisioned. This allocates all necessary resources to the guest, such as CPU cores, virtual disk, and so on. 17. Click Finish. After clicking Finished, wait while the system installs the selected ISO image onto the guest's virtual disk. When this process is complete, you can deploy the guest. Note: You can also skip the Provisioned state and instead go straight to the Deployed state if you are confident of your guest configuration. Provisioning first and then deploying makes it more straightforward to make changes to the slots to which your guests are allocated if you find you need to make changes. Setting a vcmp guest to the Deployed state Until you deploy a vcmp guest, your vcmp host has no medium for provisioning and running the BIG-IP modules that you can use to process traffic. 1. Ensure that you are still logged in to the vcmp host using the management IP address. 2. On the Main tab, click vcmp > Guest List. 3. In the Name column, click the name of the vcmp guest that you want to deploy. 4. From the Requested State list, select either Provisioned or Deployed. 5. Click Update. Important: Depending on the extent of the changes made to the vcmp guest, the guest may reboot. After moving a vcmp guest to the Deployed state, wait while the guest boots and becomes accessible. Then, you can log into the vcmp guest to provision specific BIG-IP modules. Provisioning a BIG-IP module within a guest Before you can access a guest to provision BIG-IP modules, the vcmp guest must be in the Deployed state. You determine which BIG-IP modules run within a guest by provisioning the modules. For example, if you want guesta to run LTM and GTM, log into guesta and provision it with LTM and GTM. If you want guestb to run LTM and ASM, log into guestb and provision it with BIG-IP LTM and BIG-IP ASM. Bear in mind that guests inherit the licenses of the vcmp host on which they were created, so any BIG-IP 25

26 Initial vcmp Setup modules that you want to provision on a guest must be included in the license you installed with the vcmp host. Note: This procedure applies to guests in Bridged mode only. Guests in isolated mode can be accessed only using vconsole and tmsh. 1. Use a browser and the management IP address that you configured for the guest to log in to the guest. If the system prompts you to run the Setup Utility, do not. Instead, complete this task to produce an initial configuration better suited for a vcmp guest. The BIG-IP Configuration utility opens so that you can configure the guest. 2. On the Main tab, click System > Resource Provisioning. 3. In the Resource Provisioning (Licensed Modules) area, from the Local Traffic (LTM) list, select Minimal, Nominal, or Dedicated, depending on your needs. 4. Click Update. Important: Depending on the extent of the changes made to the vcmp guest, the guest may reboot. After provisioning the module from within the guest, create self IP addresses and assign a vcmp host VLAN to each one. The vcmp host VLANs that you assign to these self IP addresses are the VLANs you created before creating the guest. Creating a self IP for a VLAN Ensure that you have at least one VLAN or VLAN group configured before you create a self IP address. Self IP addresses enable the BIG-IP system, and other devices on the network, to route application traffic through the associated VLAN or VLAN group. 1. On the Main tab, click Network > Self IPs. The Self IPs screen opens. 2. Click Create. The New Self IP screen opens. 3. In the Name field, type a unique name for the self IP. 4. In the IP Address field, type an IPv4 or IPv6 address. This IP address should represent the address space of the VLAN that you specify with the VLAN/Tunnel setting. 5. In the Netmask field, type the network mask for the specified IP address. 6. From the VLAN/Tunnel list, select the VLAN to associate with this self IP address. On the internal network, select the VLAN that is associated with an internal interface or trunk. On the external network, select the VLAN that is associated with an external interface or trunk. 7. From the Port Lockdown list, select Allow Default. 8. Click Finished. The screen refreshes, and displays the new self IP address in the list. The BIG-IP system can send and receive traffic through the specified VLAN or VLAN group. 26

27 vcmp Systems: Configuration Overview: Verifying initial vcmp configuration Verifying your vcmp configuration confirms that the setup performed up to this point is functioning properly. Once you establish that the vcmp configuration is correct, you will likely need to create a profile, pools, and virtual server that are tailored to your network topology before your guest can begin processing LTM traffic. Task summary Creating a pool to process HTTP traffic Creating a virtual server to manage HTTP traffic Creating a pool to process HTTP traffic You can create a pool of web servers to process HTTP requests. 1. On the Main tab, click Local Traffic > Pools. The Pool List screen opens. 2. Click Create. The New Pool screen opens. 3. In the Name field, type a unique name for the pool. 4. For the Health Monitors setting, from the Available list, select the http monitor, and click << to move the monitor to the Active list. 5. From the Load Balancing Method list, select how the system distributes traffic to members of this pool. The default is Round Robin. 6. For the Priority Group Activation setting, specify how to handle priority groups: Select Disabled to disable priority groups. This is the default option. Select Less than, and in the Available Members field type the minimum number of members that must remain available in each priority group in order for traffic to remain confined to that group. 7. Using the New Members setting, add each resource that you want to include in the pool: a) Type an IP address in the Address field. b) Type 80 in the Service Port field, or select HTTP from the list. c) (Optional) Type a priority number in the Priority field. d) Click Add. 8. Click Finished. The new pool appears in the Pools list. Creating a virtual server to manage HTTP traffic You can create a virtual server to manage HTTP traffic as either a host virtual server or a network virtual server. 1. On the Main tab, click Local Traffic > Virtual Servers. 27

28 Initial vcmp Setup The Virtual Server List screen opens. 2. Click the Create button. The New Virtual Server screen opens. 3. In the Name field, type a unique name for the virtual server. 4. For the Destination setting, in the Address field, type the IP address you want to use for the virtual server. The IP address you type must be available and not in the loopback network. 5. In the Service Port field, type 80, or select HTTP from the list. 6. From the HTTP Profile list, select http. 7. In the Resources area of the screen, from the Default Pool list, select a pool name. 8. Click Finished. The HTTP virtual server appears in the list of existing virtual servers on the Virtual Server List screen. 28

29 Chapter 3 Create an Active-Standby Configuration Overview: Creating an active-standby DSC configuration DSC prerequisite worksheet Task summary Implementation result

30 Create an Active-Standby Configuration Overview: Creating an active-standby DSC configuration The most common TMOS device service clustering (DSC ) implementation is an active-standby configuration, where a single traffic group is active on one of the devices in the device group and is in a standby state on a peer device. If failover occurs, the standby traffic group on the peer device becomes active and begins processing the application traffic. To implement this DSC implementation, you can create a Sync-Failover device group. A Sync-Failover device group with two or more members and one traffic group provides configuration synchronization and device failover, and optionally, connection mirroring. If the device with the active traffic group goes offline, the traffic group becomes active on a peer device, and application processing is handled by that device. Figure 1: A two-member Sync-Failover device group for an active-standby configuration About DSC configuration on a VIPRION system The way you configure device service clustering (DSC ) (also known as redundancy) on a VIPRION system varies depending on whether the system is provisioned to run the vcmp feature. For non-vcmp systems For a device group that consists of VIPRION systems that are not licensed and provisioned for vcmp, each VIPRION cluster constitutes an individual device group member. The following table describes the IP addresses that you must specify when configuring redundancy. Table 1: Required IP addresses for DSC configuration on a non-vcmp system Feature Device trust ConfigSync IP addresses required The primary floating management IP address for the VIPRION cluster. The unicast non-floating self IP address assigned to VLAN internal. Failover Recommended: The unicast non-floating self IP address that you assigned to an internal VLAN (preferably VLAN HA), as well as a multicast address. Alternative: All unicast management IP addresses that correspond to the slots in the VIPRION cluster. 30

31 vcmp Systems: Configuration Feature Connection mirroring IP addresses required For the primary address, the non-floating self IP address that you assigned to VLAN HA. The secondary address is not required, but you can specify any non-floating self IP address for an internal VLAN.. For vcmp systems On a vcmp system, the devices in a device group are virtual devices, known as vcmp guests. You configure device trust, config sync, failover, and mirroring to occur between equivalent vcmp guests in separate chassis. For example, if you have a pair of VIPRION systems running vcmp, and each system has three vcmp guests, you can create a separate device group for each pair of equivalent guests. Table 4.2 shows an example. Table 2: Sample device groups for two VIPRION systems with vcmp Device groups for vcmp Device group members Device-Group-A Guest1 on chassis1 Guest1 on chassis2 Device-Group-B Guest2 on chassis1 Guest2 on chassis2 Device-Group-C Guest3 on chassis1 Guest3 on chassis2 By isolating guests into separate device groups, you ensure that each guest synchronizes and fails over to its equivalent guest. The following table describes the IP addresses that you must specify when configuring redundancy: Table 3: Required IP addresses for DSC configuration on a VIPRION system with vcmp Feature Device trust ConfigSync IP addresses required The cluster management IP address of the guest. The non-floating self IP address on the guest that is associated with VLAN internal on the host. Failover Recommended: The unicast non-floating self IP address on the guest that is associated with an internal VLAN on the host (preferably VLAN HA), as well as a multicast address. Alternative: The unicast management IP addresses for all slots configured for the guest. Connection mirroring For the primary address, the non-floating self IP address on the guest that is associated with VLAN internal on the host. The secondary address is not required, but you can specify any non-floating self IP address on the guest that is associated with an internal VLAN on the host. 31

32 Create an Active-Standby Configuration DSC prerequisite worksheet Before you set up device service clustering (DSC ), you must configure these BIG-IP components on each device that you intend to include in the device group. Table 4: DSC deployment worksheet Configuration component Hardware, licensing, and provisioning BIG-IP software version Management IP addresses FQDN User name and password root folder properties VLANs Self IP addresses Considerations Devices in a device group must match as closely as possible with respect to product licensing and module provisioning. Heterogeneous hardware platforms within a device group are supported. Each device must be running BIG-IP version 11.x. This ensures successful configuration synchronization. Each device must have a management IP address, a network mask, and a management route defined. Each device must have a fully-qualified domain name (FQDN) as its host name. Each device must have a user name and password defined on it that you will use when logging in to the BIG-IP Configuration utility. The platform properties for the root folder must be set correctly (Sync-Failover and traffic-group-1). You must create these VLANs on each device, if you have not already done so: A VLAN for the internal network, named internal A VLAN for the external network, named external A VLAN for failover communications, named HA You must create these self IP addresses on each device, if you have not already done so: Two self IP addresses (floating and non-floating) on the same subnet for VLAN internal. Two self IP addresses (floating and non-floating) on the same subnet for VLAN external. A non-floating self IP address on the internal subnet for VLAN HA. Note: When you create floating self IP addresses, the BIG-IP system automatically adds them to the default floating traffic group, traffic-group-1. To add a self IP address to a different traffic group, you must modify the value of the self IP address Traffic Group property. Important: If the BIG-IP device you are configuring is accessed using Amazon Web Services, then the IP address you specify must be the floating IP address for high availability fast failover that you configured for the EC2 instance. Port lockdown For self IP addresses that you create on each device, you should verify that the Port Lockdown setting is set to Allow All, All Default, or Allow Custom. Do not specify None. 32

33 vcmp Systems: Configuration Configuration component Application-related objects Time synchronization Device certificates Considerations You must create any virtual IP addresses and optionally, SNAT translation addresses, as part of the local traffic configuration. You must also configure any iapps application services if they are required for your application. When you create these addresses or services, the objects automatically become members of the default traffic group, traffic-group-1. The times set by the NTP service on all devices must be synchronized. This is a requirement for configuration synchronization to operate successfully. Verify that each device includes an x509 device certificate. Devices with device certificates can authenticate and therefore trust one another, which is a prerequisite for device-to-device communication and data exchange. Task summary Use the tasks in this implementation to create a two-member device group, with one active traffic group, that syncs the BIG-IP configuration to the peer device and provides failover capability if the peer device goes offline. Note that on a vcmp system, the devices in a specific device group are vcmp guests, one per chassis. Important: When you use this implementation, F5 Networks recommends that you synchronize the BIG-IP configuration twice, once after you create the device group, and again after you specify the IP addresses for failover. Task list Specifying an IP address for config sync Specifying an IP address for connection mirroring Specifying the HA capacity of a device Establishing device trust Creating a Sync-Failover device group Syncing the BIG-IP configuration to the device group Specifying IP addresses for failover communication Syncing the BIG-IP configuration to the device group Specifying an IP address for config sync Before configuring the config sync address, verify that all devices in the device group are running the same version of BIG-IP system software. You perform this task to specify the IP address on the local device that other devices in the device group will use to synchronize their configuration objects to the local device. Note: You must perform this task locally on each device in the device group. 1. Confirm that you are logged in to the actual device you want to configure. 2. On the Main tab, click Device Management > Devices. This displays a list of device objects discovered by the local device. 33

34 Create an Active-Standby Configuration 3. In the Name column, click the name of the device to which you are currently logged in. 4. From the Device Connectivity menu, choose ConfigSync. 5. For the Local Address setting, retain the displayed IP address or select another address from the list. F5 Networks recommends that you use the default value, which is the self IP address for VLAN internal. This address must be a non-floating self IP address and not a management IP address. Important: If the BIG-IP device you are configuring is accessed using Amazon Web Services, then the internal self IP address that you specify must be the internal private IP addresses that you configured for this EC2 instance as the Local Address. 6. Click Update. After performing this task, the other devices in the device group can sync their configurations to the local device. Specifying an IP address for connection mirroring You can specify the local self IP address that you want other devices in a device group to use when mirroring their connections to this device. Connection mirroring ensures that in-process connections for an active traffic group are not dropped when failover occurs. You typically perform this task when you initially set up device service clustering (DSC ). Note: You must perform this task locally on each device in the device group. 1. Confirm that you are logged in to the actual device you want to configure. 2. On the Main tab, click Device Management > Devices. This displays a list of device objects discovered by the local device. 3. In the Name column, click the name of the device to which you are currently logged in. 4. From the Device Connectivity menu, choose Mirroring. 5. For the Primary Local Mirror Address setting, retain the displayed IP address or select another address from the list. The recommended IP address is the self IP address for either VLAN HA or VLAN internal. Important: If the BIG-IP device you are configuring is accessed using Amazon Web Services, then the self IP address you specify must be one of the private IP addresses that you configured for this EC2 instance as the Primary Local Mirror Address. 6. For the Secondary Local Mirror Address setting, retain the default value of None, or select an address from the list. This setting is optional. The system uses the selected IP address in the event that the primary mirroring address becomes unavailable. 7. Click Update. In addition to specifying an IP address for mirroring, you must also enable connection mirroring on the relevant virtual servers on this device. 34

35 vcmp Systems: Configuration Specifying the HA capacity of a device Before you perform this task, verify that this device is a member of a device group and that the device group contains three or more devices. You perform this task when you have more than one type of hardware platform in a device group and you want to configure load-aware failover. Load-aware failover ensures that the BIG-IP system can intelligently select the next-active device for each active traffic group in the device group when failover occurs. As part of configuring load-aware failover, you define an HA capacity to establish the amount of computing resource that the device provides relative to other devices in the device group. Note: If all devices in the device group are the same hardware platform, you can skip this task. 1. On the Main tab, click Device Management > Devices. This displays a list of device objects discovered by the local device. 2. In the Name column, click the name of the device for which you want to view properties. This displays a table of properties for the device. 3. In the HA Capacity field, type a relative numeric value. You need to configure this setting only when you have varying types of hardware platforms in a device group and you want to configure load-aware failover. The value you specify represents the relative capacity of the device to process application traffic compared to the other devices in the device group. Important: If you configure this setting, you must configure the setting on every device in the device group. If this device has half the capacity of a second device and a third of the capacity of a third device in the device group, you can specify a value of 100 for this device, 200 for the second device, and 300 for the third device. When choosing the next active device for a traffic group, the system considers the capacity that you specified for this device. 4. Click Update. After you perform this task, the BIG-IP system uses the HA Capacity value to calculate the current utilization of the local device, to determine the next-active device for failover of other traffic groups in the device group. Establishing device trust Before you begin this task, verify that: Each BIG-IP device that is to be part of the local trust domain has a device certificate installed on it. The local device is designated as a certificate signing authority. You perform this task to establish trust among devices on one or more network segments. Devices that trust each other constitute the local trust domain. A device must be a member of the local trust domain prior to joining a device group. By default, the BIG-IP software includes a local trust domain with one member, which is the local device. You can choose any one of the BIG-IP devices slated for a device group and log into that device to add other devices to the local trust domain. For example, devices A, B, and C each initially shows only itself as a member of the local trust domain. To configure the local trust domain to include all three devices, you can simply log into device A and add devices B and C to the local trust domain. Note that there is no need to repeat this process on devices B and C. 35

36 Create an Active-Standby Configuration 1. On the Main tab, click Device Management > Device Trust, and then either Peer List or Subordinate List. 2. Click Add. 3. Type a device IP address, administrator user name, and administrator password for the remote BIG-IP device with which you want to establish trust. The IP address you specify depends on the type of BIG-IP device: If the BIG-IP device is a non-viprion device, type the management IP address for the device. If the BIG-IP device is a VIPRION device that is not licensed and provisioned for vcmp, type the primary cluster management IP address for the cluster. If the BIG-IP device is a VIPRION device that is licensed and provisioned for vcmp, type the cluster management IP address for the guest. If the BIG-IP device is an Amazon Web Services EC2 device, type one of the Private IP addresses created for this EC2 instance. 4. Click Retrieve Device Information. 5. Verify that the certificate of the remote device is correct. 6. Verify that the name of the remote device is correct. 7. Verify that the management IP address and name of the remote device are correct. 8. Click Finished. The device you added is now a member of the local trust domain. Repeat this task for each device that you want to add to the local trust domain. Creating a Sync-Failover device group This task establishes failover capability between two or more BIG-IP devices. If an active device in a Sync-Failover device group becomes unavailable, the configuration objects fail over to another member of the device group and traffic processing is unaffected. You perform this task on any one of the authority devices within the local trust domain. Repeat this task for each Sync-Failover device group that you want to create for your network configuration. 1. On the Main tab, click Device Management > Device Groups. 2. On the Device Groups list screen, click Create. The New Device Group screen opens. 3. Type a name for the device group, select the device group type Sync-Failover, and type a description for the device group. 4. From the Configuration list, select Advanced. 5. In the Configuration area of the screen, select a host name from the Available list for each BIG-IP device that you want to include in the device group, including the local device. Use the Move button to move the host name to the Includes list. The Available list shows any devices that are members of the device's local trust domain but not currently members of a Sync-Failover device group. A device can be a member of one Sync-Failover group only. 6. For the Network Failover setting, select or clear the check box: Select the check box if you want device group members to handle failover communications by way of network connectivity. Clear the check box if you want device group members to handle failover communications by way of serial cable (hard-wired) connectivity. You must enable network failover for any device group that contains three or more members. 36

37 vcmp Systems: Configuration 7. For the Automatic Sync setting, select or clear the check box: Select the check box when you want the BIG-IP system to automatically sync the BIG-IP configuration data whenever a config sync operation is required. In this case, the BIG-IP system syncs the configuration data whenever the data changes on any device in the device group. Clear the check box when you want to manually initiate each config sync operation. In this case, F5 networks recommends that you perform a config sync operation whenever configuration data changes on one of the devices in the device group. 8. For the Full Sync setting, select or clear the check box: Select the check box when you want all sync operations to be full syncs. In this case, the BIG-IP system syncs the entire set of BIG-IP configuration data whenever a config sync operation is required. Clear the check box when you want all sync operations to be incremental (the default setting). In this case, the BIG-IP system syncs only the changes that are more recent than those on the target device. When you select this option, the BIG-IP system compares the configuration data on each target device with the configuration data on the source device and then syncs the delta of each target-source pair. If you enable incremental synchronization, the BIG-IP system might occasionally perform a full sync for internal reasons. This is a rare occurrence and no user intervention is required. 9. In the Maximum Incremental Sync Size (KB) field, retain the default value of 1024, or type a different value. This value specifies the total size of configuration changes that can reside in the incremental sync cache. If the total size of the configuration changes in the cache exceeds the specified value, the BIG-IP system performs a full sync whenever the next config sync operation occurs. 10. Click Finished. You now have a Sync-Failover type of device group containing BIG-IP devices as members. Syncing the BIG-IP configuration to the device group Before you sync the configuration, verify that the devices targeted for config sync are members of a device group and that device trust is established. This task synchronizes the BIG-IP configuration data from the local device to the devices in the device group. This synchronization ensures that devices in the device group operate properly. When synchronizing self IP addresses, the BIG-IP system synchronizes floating self IP addresses only. Important: You perform this task on either of the two devices, but not both. 1. On the Main tab, click Device Management > Overview. 2. In the Device Groups area of the screen, in the Name column, select the name of the relevant device group. The screen expands to show a summary and details of the sync status of the selected device group, as well as a list of the individual devices within the device group. 3. In the Devices area of the screen, in the Sync Status column, select the device that shows a sync status of Changes Pending. 4. In the Sync Options area of the screen, select Sync Device to Group. 5. Click Sync. The BIG-IP system syncs the configuration data of the selected device in the Device area of the screen to the other members of the device group. 37

38 Create an Active-Standby Configuration Except for non-floating self IP addresses, the entire set of BIG-IP configuration data is replicated on each device in the device group. Specifying IP addresses for failover communication You typically perform this task during initial Device Service Clustering (DSC ) configuration, to specify the local IP addresses that you want other devices in the device group to use for continuous health-assessment communication with the local device. You must perform this task locally on each device in the device group. Note: The IP addresses that you specify must belong to route domain Confirm that you are logged in to the actual device you want to configure. 2. On the Main tab, click Device Management > Devices. This displays a list of device objects discovered by the local device. 3. In the Name column, click the name of the device to which you are currently logged in. 4. From the Device Connectivity menu, choose Failover. 5. For the Failover Unicast Configuration settings, click Add for each IP address on this device that other devices in the device group can use to exchange failover messages with this device. The unicast IP addresses you specify depend on the type of device: Platform Non-VIPRION VIPRION without vcmp VIPRION with vcmp Action Type a self IP address associated with an internal VLAN (preferably VLAN HA) and the management IP address for the device. Type the self IP address for an internal VLAN (preferably VLAN HA) and the management IP addresses for all slots in the VIPRION cluster. Note that if you also configure a multicast address (using the Use Failover Multicast Address setting), then these management IP addresses are not required. Type a self IP address that is defined on the guest and associated with an internal VLAN on the host (preferably VLAN HA). You must also specify the management IP addresses for all of the slots configured for the guest. Note that if you also configure a multicast address (using the Use Failover Multicast Address setting), then these management IP addresses are not required. 6. To enable the use of a failover multicast address on a VIPRION platform (recommended), then for the Use Failover Multicast Address setting, select the Enabled check box. 7. If you enabled Use Failover Multicast Address, either accept the default Address and Port values, or specify values appropriate for the device. If you revise the default Address and Port values, but then decide to revert to the default values, click Reset Defaults. 8. Click Update. After you perform this task, other devices in the device group can send failover messages to the local device using the specified IP addresses. Syncing the BIG-IP configuration to the device group Before you sync the configuration, verify that the devices targeted for config sync are members of a device group and that device trust is established. 38

39 vcmp Systems: Configuration This task synchronizes the BIG-IP configuration data from the local device to the devices in the device group. This synchronization ensures that devices in the device group operate properly. When synchronizing self IP addresses, the BIG-IP system synchronizes floating self IP addresses only. Important: You perform this task on either of the two devices, but not both. 1. On the Main tab, click Device Management > Overview. 2. In the Device Groups area of the screen, in the Name column, select the name of the relevant device group. The screen expands to show a summary and details of the sync status of the selected device group, as well as a list of the individual devices within the device group. 3. In the Devices area of the screen, in the Sync Status column, select the device that shows a sync status of Changes Pending. 4. In the Sync Options area of the screen, select Sync Device to Group. 5. Click Sync. The BIG-IP system syncs the configuration data of the selected device in the Device area of the screen to the other members of the device group. Except for non-floating self IP addresses, the entire set of BIG-IP configuration data is replicated on each device in the device group. Implementation result You now have a Sync-Failover device group set up with an active-standby DSC configuration. This configuration uses the default floating traffic group (named traffic-group-1), which contains the application-specific floating self IP and virtual IP addresses, and is initially configured to be active on one of the two devices. If the device with the active traffic group goes offline, the traffic group becomes active on the other device in the group, and application processing continues. 39

40

41 Chapter 4 Understanding Clusters Cluster overview Viewing cluster properties Viewing cluster member properties Enabling and disabling cluster members Changing a cluster-related management IP address

42 Understanding Clusters Cluster overview The slots in a VIPRION chassis work together as a single, powerful unit. This entity is called a cluster. The size of the cluster depends on the number of running blades installed in the chassis. Blades in the cluster share the overall workload, and can be configured to mirror each others connections so that if a blade is taken out of service or becomes unavailable for some reason, any in-process connections remain intact. Important: The discussion of clusters does not apply to appliances. F5 Networks clustering technology is implemented only on systems that use blades and slots. When a blade is installed in a slot and turned on, it automatically becomes a member of the cluster. One of the first tasks performed as part of the platform installation is to insert blades and assign a unique cluster IP address to the primary blade in the cluster. The cluster IP address is a floating management IP address used to access the primary blade to configure the system. If the primary blade becomes unavailable for any reason, the primary designation moves to a different blade, and the cluster IP address floats to that blade. This ensures that you can always access the cluster using the cluster IP address, even when the primary blade changes. When you log in to the system using the cluster IP address, you can configure features such as trunks, VLANs, administrative partitions, and virtual servers. If you have a redundant system configuration, you can configure failover IP addresses, as well as connection mirroring between clusters. Viewing cluster properties You can use the BIG-IP Configuration utility to view the properties for the cluster. 1. Use a browser to log in to the management IP address of the VIPRION chassis or appliance. This logs you in to the vcmp host. 2. On the Main tab, click System > Clusters. The Cluster screen opens, showing the properties of the cluster, and listing the cluster members. Cluster properties The Cluster screen displays the properties of the cluster. Property Name Cluster IP Address Network Mask Primary Member Software Version Description Displays the name of the cluster. Displays the IP address assigned to the cluster. Click this IP address to change it. Displays the network mask for the cluster IP address. Displays the number of the slot that holds the primary blade in the cluster. Displays the version number of the BIG-IP software that is running on the cluster. 42

43 vcmp Systems: Configuration Property Software Build Hotfix Build Chassis 400-level BOM Status Description Displays the build number of the BIG-IP software that is running on the cluster. Displays the build number of any BIG-IP software hotfix that is running on the cluster. Displays the bill-of-materials (BOM) number for the chassis. Displays an icon and descriptive text that indicates whether there are sufficient available members of the cluster. Viewing cluster member properties You can use the BIG-IP Configuration utility to view the properties for cluster members. 1. Use a browser to log in to the management IP address of the VIPRION chassis or appliance. This logs you in to the vcmp host. 2. On the Main tab, click System > Clusters. The Cluster screen opens, showing the properties of the cluster, and listing the cluster members. 3. To display the properties for one cluster member, click the slot number of that member. The Cluster Member properties screen opens, showing the properties of that member. Cluster member properties In addition to displaying the properties of the cluster, the Cluster screen also lists information about members of the cluster. The table lists the information associated with each cluster member. Property Status Slot Blade serial number Enabled Primary HA State Description The Status column indicates whether the cluster member is available or unavailable. The Slot column indicates the number of the slot. Click this number to display the properties of that cluster member. The Blade Serial Number column displays the serial number for the blade currently in that slot. The Enabled column indicates whether that cluster member is currently enabled. The Primary column indicates whether that cluster member is currently the primary slot. The HA State column indicates whether the cluster member is used in a redundant system configuration for high availability. 43

44 Understanding Clusters Enabling and disabling cluster members To gracefully drain the connections from a cluster member before you take that blade out of service, you can mark that cluster member disabled. Before you can return that member to service, you need to enable it. Important: Perform this task while logged in to the vcmp host; not from a guest. 1. Use a browser and the cluster management IP address of the vcmp host to log in to the vcmp host (hypervisor) and access the BIG-IP Configuration utility. 2. On the Main tab, click System > Clusters. The Cluster screen opens, showing the properties of the cluster, and listing the cluster members. 3. Locate the cluster member you want to enable or disable, and select the box to the left of the Status icon. 4. Click Enable or Disable/Yield. Changing a cluster-related management IP address You can use the BIG-IP Configuration utility to view or change the properties for a vcmp cluster. Important: Perform this task while logged in to the vcmp host; not from a guest. 1. Use a browser and the cluster management IP address of the vcmp host to log in to the vcmp host (hypervisor) and access the BIG-IP Configuration utility. 2. On the Main tab, click System > Clusters. The Cluster screen opens, showing the properties of the cluster, and listing the cluster members. 3. On the menu bar, click Management IP Address. The Management IP Address screen opens. 4. Locate the specific management IP address or cluster member IP address that you would like to change, and type the new IP address. 5. Click Update. The specific management IP address or cluster member IP address that you edited is changed. You can now use that new address to access the cluster. Cluster-related IP addresses The cluster-related addresses that you can modify are defined in the table. Setting Type Cluster IP address Cluster IP address Setting IP Address Network Mask Description Specifies the management IP address that you want to assign to the cluster. This IP address is used to access the Configuration utility, as well as to function as a cluster identifier for the peer cluster in a device service clustering configuration. Specifies the network mask for the cluster IP address. 44

45 vcmp Systems: Configuration Setting Type Cluster IP address Cluster Member IP Address Cluster Member IP Address Cluster Member IP Address Cluster Member IP Address Setting Management Route Slot 1 IP Address Slot 2 IP Address Slot 3 IP Address Slot 4 IP Address Description Specifies the gateway for the cluster IP address. Typically, this is the default route. Specifies the management IP address associated with slot 1 of the cluster. You can also set this value to None. Specifies the management IP address associated with slot 2 of the cluster. You can also set this value to None. Specifies the management IP address associated with slot 3 of the cluster. You can also set this value to None. Specifies the management IP address associated with slot 4 of the cluster. You can also set this value to None. 45

46

47 Chapter 5 Understanding vcmp Hosts Overview: Managing vcmp hosts Viewing host properties for slots

48 Understanding vcmp Hosts Overview: Managing vcmp hosts With vcmp initial setup successfully completed to process application traffic, you will likely want to manage the configuration of the vcmp host to optimize performance. The vcmp host is the system-wide hypervisor that makes it possible for you to create, view, and manage all guests on the system. A vcmp host allocates system resources to guests as needed. vcmp host configuration encompasses these activities: Viewing host properties Creating additional VLANs for guests if needed Adding additional vcmp guests Managing application volumes Note: To manage a vcmp system, you must have the Administrator user role assigned to your user account. Important: Do not configure BIG-IP module features (such as BIG-IP Local Traffic Manager virtual servers, pools, and profiles) when logged in to the vcmp host. Use the vcmp host to create and manage vcmp guests and to perform Layer 2 network configuration only. Attempting to configure BIG-IP modules while logged in to the vcmp host produces unwanted results. Always log in to the relevant vcmp guest to configure the features of a BIG-IP module. Viewing host properties for slots You must have created at least one vcmp guest on the system to view host properties. Use the BIG-IP Configuration utility to view the host properties for all slots on the system or for a single slot. The host properties that you can view are: The state of each guest The slot numbers on which each guest runs The number of CPU cores allocated to each guest 1. Use a browser to log in to the management IP address of the VIPRION chassis or appliance. This logs you in to the vcmp host. 2. On the Main tab, click vcmp > Host Properties. 3. View host properties for all slots, or in the upper right corner of the screen, from the View list, select a slot number. The screen displays the host properties for the chosen slots. vcmp host properties This topic describes the vcmp host properties on the BIG-IP system. 48

49 vcmp Systems: Configuration Property Name State On Slots Number of Cores Value Configured, Provisioned, or Deployed One or more numeric values in the range of 1 through 4. A numeric value Description The state of the named guest. The slot numbers pertaining to each guest. The number of CPU cores currently allocated to the named guest. 49

50

51 Chapter 6 Understanding vcmp Guests About vcmp guests About network modes for a vcmp guest Modifying the properties of a vcmp guest Overview: Blade swap for vcmp guest About software image selection and live installation About vcmp guest states About system resource allocation vcmp guest modification considerations

52 Understanding vcmp Guests About vcmp guests A vcmp guest is an object that you create on the vcmp system for the purpose of running one or more BIG-IP modules. For example, a typical guest might run both BIG-IP Local Traffic Manager and BIG-IP Global Traffic Manager. Each guest has its own portion of system resources (such as CPU cores and disk space) allocated to it, which makes the guest appear as if it were a separate BIG-IP device. On a vcmp system, the number of guests that you can run simultaneously, depends on licensing and hardware type. In addition to running BIG-IP modules, each guest contains its own instance of TMOS. This TMOS instance gives you the ability to provision, configure, and manage certain network components (such as self IP addresses) and any BIG-IP modules within the guest. The illustration shows three guests running on a BIG-IP system. Guest 1 runs on a single slot only. Guest 2 and Guest 3 each run on all available slots. Figure 2: Example illustration of guests running on a BIG- IP system Important: In addition to other considerations, when considering whether to create a single slot or multi-slot guest, bear in mind that recovery from a blade hot swap is much more straightforward for multi-slot guests. About network modes for a vcmp guest You can configure each vcmp guest to operate in one of two modes: Bridged or Isolated. The mode you choose specifies whether the guest is bridged to or isolated from the vcmp host's management network. 52

53 vcmp Systems: Configuration About the Bridged network mode Bridged mode is the default network mode for a vcmp guest. This mode provides full Layer 2 access between guests, and creates a bridge between each guest's management interface, the host's management interface, and devices connected to the host's front-panel management port. Typically, you configure a guest's management port to be on the same IP network as the host's management port, with a gateway identical to the host's management gateway. This allows you to make TCP connections (for SSH, HTTP, and so on) easily from either the host or the external network to the guest, or from the guest to the host or external network. Although the guest and the host share the host's Ethernet connection, the guest appears as a separate device on the local network, with its own MAC address and IP address. About the Isolated network mode Isolated mode isolates the guest from the management network. As in Bridged mode, a guest in Isolated mode cannot communicate with other guests on the system. Also, the only way that a guest can communicate with the vcmp host is through the console port or through a self IP address on the guest that allows traffic through port 22. Note: Although a guest in Isolated mode cannot communicate directly with the management network, you can configure the guest to communicate to external networks indirectly. You do this by configuring network routing or a firewall on the guest's operating system. About deployed guests and network modes If the guest is already deployed: Setting the network mode from Bridged to Isolated causes the vcmp host to remove all of the guest's management interfaces from its bridged management network. This has the effect of immediately disconnecting the guest's VMs from the physical management network. Setting the network mode from Isolated to Bridged causes the vcmp host to dynamically add the guest's management interfaces to the bridged management network. This immediately connects all of the guest's VMs to the physical management network. Changing this property while the guest is in the Configured or Provisioned state has no immediate effect. Modifying the properties of a vcmp guest You can use the BIG-IP Configuration utility to modify the properties of an existing vcmp guest. 1. On the Main tab, click vcmp > Guest List. 2. In the Name column, click the name of the vcmp guest that you want to modify. 3. From the Properties list, select Advanced. 4. Change the values of the properties you want to modify. 5. Click Update. Important: Depending on the extent of the changes made to the vcmp guest, the guest may reboot. Viewing the properties of a vcmp guest You can use the BIG-IP Configuration utility to view the properties of vcmp guests. 53

54 Understanding vcmp Guests 1. On the Main tab, click vcmp > Guest List. 2. In the Name column, click the name of the vcmp guest that you want to view. The system displays the properties of the guest. Overview: Blade swap for vcmp guest When you remove and replace blades, and want to preserve the existing configuration, you may need to migrate a guest. This is true when you need to swap all of the blades upon which your guest resides. On multiple slot guests, configuration information is stored on all blades, so when you remove a blade, the configuration is retained. But when you swap a single slot guest, or all slots of a multiple slot guest, you must take care to migrate the guest before you swap. This task guides you through the process of migrating your guest to another slot for the duration of the hot swap process and then migrating it back after the swap. Although this task preserves your guest and all of its settings, the easier (and preferable) method is to just save the BIG-IP configuration objects configured on your guest (as a UCS file), create a new guest, and then import the UCS file to the new guest. For more information on archiving and importing BIG-IP configuration objects, refer to the F5 Networks AskF5 Knowledge Base web site, When you swap out a blade that hosts a single slot vcmp guest, migrate the guest to another slot before you swap out the blade to preserve the BIG-IP configuration objects through the swap process. Migrating a single-slot guest to another slot copies the virtual disk and the configuration objects it contains. When you swap out the blade and redeploy the guest, the guest can resume traffic processing. Disabling a vcmp guest When you disable a guest, the BIG-IP system deallocates its resources (such as CPU cores, physical memory, and virtual disks). Once disabled, you can edit the vcmp guest, or you can migrate the guest to another slot and its resources are available for consumption by another guest. 1. On the Main tab, click vcmp > Guest List. 2. In the Name column, find the name of the vcmp guest that you want to disable. 3. Select the check box to the left of the guest name. 4. Click Disable. The BIG-IP system releases the resources dedicated to the guest. Migrating a vcmp guest When you migrate a guest from a slot about to be hot swapped, you determine where that guest will migrate using the Allowed Slots List. 1. On the Main tab, click vcmp > Guest List. 2. Analyze the vcmp guest allocation to determine on which slot your guest is currently deployed and to which slot (or slots) you want it to migrate. 3. In the Name column, click the name of the vcmp guest that you want to modify. The system displays the properties of the guest. 54

55 vcmp Systems: Configuration 4. From the Properties list, select Advanced. 5. From the Allowed Slots List, use the Move button to move the current slot number to the Available field and the slot to which you want the guest to migrate to the Selected field. (If it doesn't matter to which specific slot the guest migrates, you can also just remove the current slot from the Allowed Slots list. This identifies the specific slots to which you want your guest to migrate. 6. Click Provision or Deploy. 7. Click Update. Important: The system will begin migrating the virtual disk for the vcmp guest. Migrating a single slot guest For this task you must be logged in to the vcmp host using its management IP address, and you are in the process of migrating a single slot guest from a blade so that it can be hot swapped. Additionally, this task begins when you have either temporarily disabled guests or created dummy guests so that when you re-deploy the guest, it will migrate to the slot you intend. When you re-deploy a guest that has been disabled (change its state from configured to deployed), the vcmp host migrates that guest to the next open set of available resources. Use this procedure to migrate the guest from the blade before you perform the hot swap, and then use this procedure again to migrate the guest back to the blade after the hot swap. Important: Migrating a single slot guest to another slot is essential before performing a blade hot-swap if you want to preserve the BIG-IP configuration objects defined for that guest. 1. Ensure that you are still logged in to the vcmp host using the BIG-IP system's management IP address. 2. On the Main tab, click vcmp > Guest List. 3. In the Name column, click the name of the vcmp guest that you want to deploy. 4. From the Requested State list, select either Provisioned or Deployed. 5. Click Update. Important: Depending on the extent of the changes made to the vcmp guest, the guest may reboot. The guest migrates to the next available set of resources. It takes some time for the guest to boot and become accessible. Hot swapping a VIPRION blade You can hot swap a VIPRION blade when you need to replace it. Steps for performing a hot swap are platform dependent. Refer to the appropriate platform guide for instructions on removing and replacing a blade on an active VIPRION chassis. Option Description For VIPRION 2400 chassis Refer to "Removing a blade" and "Installing a blade" in the Platform Guide: VIPRION

56 Understanding vcmp Guests Option For VIPRION 4400 chassis Description Refer to "Removing a blade" and "Installing a blade" in the Platform Guide: VIPRION Once the new blade boots, the vcmp host adds it to the cluster, and you can migrate guests to it. About software image selection and live installation When you initially create a vcmp guest, you choose the ISO image to install for that guest. Then, when you move the guest to the Provisioned state, the vcmp host installs that ISO image onto each of the newly-created virtual disk images pertaining to that guest. Important: The initial software image is used only when the system first creates the virtual disk images. Subsequent software upgrades are done within the guest using the live installation process. About vcmp guest states A vcmp guest is always in one of these states: Configured This is the initial (and default) state for newly-created guests. In this state, the guest is not running, and no resources are allocated to the guest. The BIG-IP system does not create virtual disks for a guest until you set that guest to the Provisioned state. If you move a guest from another state to the Configured state, the BIG-IP system does not delete the virtual disks previously attached to that guest. The guest's virtual disks persist on the system. Other resources, however, such as CPU cores, are automatically de-allocated. When the guest is in the Configured state, you cannot configure the BIG-IP modules that are licensed to run within the guest; instead, you must first provision and deploy the guest, then you can provision the BIG-IP modules within the guest. Provisioned When you move a vcmp guest to the Provisioned state, the system allocates resources (CPU, memory, network interfaces, and disk space) to that guest. If this is a new guest, the system also creates virtual disks for the guest and installs the selected ISO image on them. A guest does not run while in the Provisioned state. Deployed After provisioning a guest, you deploy it. For guests in this state, the BIG-IP system attempts to start and maintain a VM on each slot for which the guest has resources allocated. If you reconfigure the properties of a guest after its initial deployment, the system immediately propagates some of those changes to all of that guest's VMs. The system immediately propagates the list of allowed VLANs. When you set up and deploy multiple guests at once, there is good reason to move each guest first to the Provisioned state. This allows you to verify that the guest allocations are satisfactory before you commit the guests to full deployment. This allows you to confirm that the virtual disk installations are successful before deploying the guests. If there is a problem with one guest s allocation or virtual disk installation, you might need to rearrange the resource allocations for your guests. Keeping the guests in the Provisioned state until you are confident in your allocations prevents you from having to shut down deployed guests to make these changes. 56

57 vcmp Systems: Configuration About system resource allocation The system resources that the BIG-IP system allocates to each guest are: CPU cores, physical memory, and virtual disk space. The system allocates resources to a guest when you set the state of the guest to Provisioned. About CPU cores allocation For single-slot guests, when the system allocates CPU cores to a guest, the system determines the best slot for the guest to run on. From the slots identified on the Allowed Slots list, the system selects the slot with the most unallocated CPU cores. For all-slot guests, the system allocates CPU cores from the available slots (as defined by the Allowed Slots setting for this guest). This illustration shows that the BIG-IP system has allocated two CPU cores to guest1, which is deployed on slot 1. Note that guest0 has no CPU cores allocated to it because the guest has not yet been deployed. Figure 3: BIG-IP system with CPU core allocations for guests Note the following: If an unavailable slot becomes available later, the system automatically re-allocates the CPU cores to each all-slot guest and to any single-slot guests previously allocated to this slot. If rebooted for any reason, the BIG-IP system persists any single-slot guest to the slot it was deployed on previously, thereby retaining the same CPU core allocation for that guest. However, if you change a guest's state at any time from Deployed to Configured, the BIG-IP system de-allocates the CPU cores for that guest. 57