Manual Chapter :
Understanding Core Features of BIG-IQ Centralized Management
Applies To:
Show Versions![Show Versions](/etc/designs/pcx/techdocs/images/expandversions.gif)
BIG-IQ Centralized Management
- 7.0.0
Understanding Core Features of BIG-IQ Centralized Management
Why should I use BIG-IQ?
You can save time by using BIG-IQ Centralized Management to manage and monitor multiple BIG-IP devices and service configurations (such as Network Security and Access) from a single, central location.
With centralized management, you can:
- Manage and monitor multiple BIG-IP devices and service configurations from one BIG-IQ Centralized Management system, rather than having to log in and manage and monitor each BIG-IP device (physical, virtual, or vCMP) individually.
- Centrally manage and monitor security policies across your BIG-IP devices, such as firewall policies and web application policies, depending on what service configurations you have installed.
- Maintain and edit shared configuration objects, such as policies, in one place, and then deploy those objects to multiple BIG-IP devices.
- Apply role based authorization within the BIG-IQ system. You can restrict roles and permissions for some users who use only a portion of the BIG-IQ system, and define broader permissions for administrative users. For example, you can permit application owners to see only their configuration objects across multiple devices, while an overall administrator can see all objects.
- Find information about objects across all configurations known to the BIG-IQ system using global search (available from the search icon on the upper right of most BIG-IQ system screens). You can restrict the scope of the search using various search options. Once an object is found, you can review additional information about that object.
What elements make up a BIG-IQ solution?
A BIG-IQ solution can involve a number of different elements. The topology for these elements depends on your needs, and on whether you include data collection devices (DCDs) in your solution. A typical solution can include the following elements:
- BIG-IQ(s)
- BIG-IP devices
- Data collection devices (optional)
- Remote storage devices (optional)
BIG-IQ
Using BIG-IQ, you can centrally manage your BIG-IP devices, performing operations such as backups, licensing, monitoring, and configuration management. Because access to each area of BIG-IQ is role-based, you can limit access to users, thus maximizing work flows while minimizing errors and potential security issues.
BIG-IP device
A BIG-IP device runs a number of licensed components designed around application availability, access control, and security solutions. These components run on top of F5
Traffic Management Operating System (TMOS). This custom operating system is an event driven operating system designed specifically to inspect network and application traffic and make real-time decisions based on the configurations you provide. The BIG-IP software runs on both hardware and virtualized environments.
BIG-IQ data collection device
A
data collection device
(DCD) is a specially provisioned BIG-IQ system that you use to manage and store alerts, events, and statistical data from one or more BIG-IP systems. Configuration tasks on the BIG-IP system determine when and how alerts or events are triggered. The alerts or events are sent to a BIG-IQ DCD, and the BIG-IQ retrieves them for your analysis. When you opt to collect statistical data from the BIG-IP devices, the DCD periodically (at an interval that you configure) retrieves those statistics from your devices, and then processes and stores that data.
The group of data collection devices that work together to store and manage your data are referred to as the
data collection cluster
. The individual data collection devices are generally referred to as nodes
. Remote storage device
The remote storage device is necessary only when your deployment includes a DCD and you plan to store backups of your events, alerts, and statistical data for disaster recovery requirements. Remote storage is also required so that you can retain this data when you upgrade your software.
Quorum DCD device
If you want an auto failover, high availability (HA) configuration, you must identify a DCD to serve as a
quorum device
. The quorum device is used to determine which BIG-IQ in the HA configuration is active. If communication is disrupted between the active and standby BIG-IQ in the HA pair, the BIG-IQ that can communicate with the quorum device becomes active. The quorum device is a DCD, so it can be included in a DCD cluster. But because it is a DCD, not a BIG-IQ, it cannot be not used as a standby BIG-IQ in an HA configuration. BIG-IQ system architecture
A simple view of the system architecture illustrates the relationship between the components of
the system.
This graphic shows a
BIG-IQ system, composed of two BIG-IQs in a high availability
configuration and a cluster of data collection devices (DCD) using remote storage, managing multiple BIG-IP
devices.
Simple BIG-IQ System Architecture
![](/content/dam/projects/techdocs/bigiq-7-0-0/central-mgmt/images/bigiq-simple-system-arch.png/_jcr_content/renditions/original)
Overview of process to centrally manage BIG-IP devices
You typically use this process to manage devices using Centralized Management. Centrally managing a BIG-IP device using the
BIG-IQ system is sometimes referred to as
declaring
management authority
(DMA) over a BIG-IP device. All required components
should be already installed on the BIG-IP device and the BIG-IQ system. You perform all
these tasks using the BIG-IQ system. Some of these tasks are optional, depending on what
you want to manage using the BIG-IQ system.- Add the BIG-IP device to the list of devices managed by the BIG-IQ system, and establish a trust relationship between the device and the BIG-IQ system. If you do not want to manage service configurations on your BIG-IP devices, the other tasks are not needed.
- Discover the service configurations on the BIG-IP device that you want to manage, such as Local Traffic, Web Application Security, and so on. You usually only need to discover the service configurations when you are first beginning to manage a BIG-IP device.
- Import the discovered configurations from the BIG-IP device to the BIG-IQ system. You usually only need to perform this task when you are first beginning to manage the BIG-IP device, or after an upgrade of BIG-IQ.
- Edit the configurations as needed on the BIG-IQ system.
- Evaluate the configurations to ensure that there will be no deployment issues.
- Deploy the updated configurations back to the BIG-IP devices.Essentially, you perform the first three tasks to initially set up centralized management of your BIG-IP devices and services. The last three tasks (edit, evaluate, and deploy) are performed regularly as you manage your BIG-IP devices and services.
About discovering BIG-IP devices and importing services
If you choose to add BIG-IP devices and import their services in
two separate steps, there's some things to keep in mind.
It's important to know a few things about services
shared between BIG-IQ and BIG-IP devices. When BIG-IQ manages BIG-IP devices, it stores
a copy of their service configuration objects. The BIG-IQ system uses the following
terms to describe configurations between BIG-IQ and BIG-IP devices:
- Theworking configurationis the configuration that is maintained and edited on the BIG-IQ system. This is the configuration you deploy to the BIG-IP device during a deployment.
- Thecurrent configurationis the configuration discovered on the BIG-IP device. This is also sometimes referred to as the running configuration. The current configuration is updated during re-import or re-discovery and before calculating differences during the deployment process. The current configuration is also updated after a successful deployment to the BIG-IP device.
- Adifferenceis when an object with the same type and name occurs in both the current configuration and the working configuration but with different data. For example, a difference would occur if the policy object Pol021 in the current configuration (imported from the BIG-IP device) contains more properties than that policy object in the working configuration (on the BIG-IQ Centralized Management system).
If you're importing services for more than one
BIG-IP device, you have to option to address any conflicts automatically in the same
way. Your options are:
- Shared - All objects shared across BIG-IP devices, except LTM profiles and monitors.
- Version-specific - Only LTM profile and monitor objects that are specific to a BIG-IP software version.
- Device-specific - Objects that are specific to a particular BIG-IP device, and are not shared among BIG-IP devices.
- Use BIG-IQ
- Keep the object in BIG-IQ system's working configuration. The next time BIG-IQ deploys a configuration to that BIG-IP device, it updates the object to match the one on BIG-IQ.
- Use BIG-IP
- Use the object from the BIG-IP device's configuration to replace the object in the BIG-IQ system's working configuration that is different. If you select this option, BIG-IQ replaces that object for all of your managed BIG-IP devices the next time it deploys a configuration.
- Create Version
- BIG-IQ creates and stores a copy of the BIG-IP device's LTM monitor or profile object (s), specific to the software version running on that BIG-IP device. If you select this option, BIG-IQ replaces that object for all the managed BIG-IP devices running that version, the next time it deploys a configuration. You can store multiple versions of LTM monitors or profiles. BIG-IQ deploys the appropriate stored version to your managed devices. BIG-IQ automatically resolves conflicts against the appropriate version the next time it imports services that contain LTM monitors or profiles.
Alternatively, you
can have BIG-IQ
stop importing any service that contains conflicts, and attempt to discover and import
the next service. If you use this option, you can rediscover and reimport the services
that failed from the BIG-IP device's Service page, and resolve each conflict
individually.
If you want to view shared objects, from the command line,
type the following command:
GET
"/mgmt/cm/shared/metadata?\$filter='category'+eq+'working-config'+and+'configData/configType'+eq+'shared'&\$select=itemKind,uriPath"
Adding BIG-IP devices to the list of managed devices
The first task in managing a BIG-IP device is to add it to the list of
devices managed by the Centralized
Management system using the Devices screens. Largely, this is making sure that the
BIG-IQ system can access the device at
the specified IP address and ports. This is sometimes referred to as
establishing trust
with the BIG-IP device.After this task is complete, all of the BIG-IQ Device functionality
(inventory reporting, backup and restore, script management, licensing, password
management, software upgrade, and so on) is available for the discovered device. If at
least one Data Collection Device (DCD) is deployed in the environment, statistics data
for device, LTM, and DNS objects can also be
collected and reported.
In environments that only require centralized device management, this
task might be the only one you need to perform. The remaining tasks are for those
environments that want to manage service configurations, such as Network Security, as
well as the devices.
Adding the BIG-IP device and establishing trust with it involves
several tasks:
- The BIG-IQ administrator adds the IP address, user name and password for an administrative user on the BIG-IP device.
- If the BIG-IP device is clustered, the administrator selects how to handle deployment to the clustered devices.
- The BIG-IP device and the BIG-IQ system exchange certificates to create a trust relationship.
- For earlier versions of BIG-IP devices, the administrator might need to update the REST framework on the BIG-IP device to be able to manage it.
Discovering the service configurations on BIG-IP devices
After the devices have been
added to the list of managed devices, you can discover and import the service
configurations for those BIG-IP devices, such as Local Traffic, Web Application
Security, and so on. In general, you want to manage all the service configurations you
discover. You always need to discover and import the Local Traffic service first, since
the other services depend upon it.
You use the Devices screens to discover configurations.
Importing service configurations
After discovering the service configurations, you need to import each
service from the device to the Centralized Management system. Before
you import the services, you can create a snapshot of your BIG-IQ service configuration
in case you want to roll back from the configuration you are about to import from the
BIG-IP device.
It's important to know a few things about services shared between BIG-IQ and BIG-IP
devices. When BIG-IQ manages BIG-IP devices, it stores a copy of their service
configuration objects. The BIG-IQ system uses the following terms to describe
configurations between BIG-IQ and BIG-IP devices:
- Theworking configurationis the configuration that is maintained and edited on the BIG-IQ system. This is the configuration you deploy to the BIG-IP device during a deployment.
- Thecurrent configurationis the configuration discovered on the BIG-IP device. This is also sometimes referred to as the running configuration. The current configuration is updated during re-import or re-discovery and before calculating differences during the deployment process. The current configuration is also updated after a successful deployment to the BIG-IP device.
- Adifferenceis when an object with the same type and name occurs in both the current configuration and the working configuration but with different data. For example, a difference would occur if the policy object Pol021 in the current configuration (imported from the BIG-IP device) contains more properties than that policy object in the working configuration (on the BIG-IQ Centralized Management system).
When importing services, BIG-IQ looks for any differences between the objects in the
service configuration on the BIG-IP device and the configuration on the BIG-IQ system,
it notifies you. To resolve these conflicts, you have a few choices, you stop trying to
import the service with a conflict and import the service later. In this case, you'll
have the opportunity to resolve each conflict individually from the BIG-IP device's
Services screen. The other option is to use a conflict resolution policy to treat
specific object types the same way when a difference is found.
There are three types of objects that can conflict:
- Shared - All objects shared across BIG-IP devices, except LTM profiles and monitors.
- Version-specific - Only LTM profile and monitor objects that are specific to a BIG-IP software version.
- Device-specific - Objects that are specific to a particular BIG-IP device, and are not shared among BIG-IP devices.
If you're importing services for more than one
BIG-IP device, you have to option to address any conflicts automatically in the same
way. Your options are:
- Use BIG-IQ
- Keep the object in BIG-IQ system's working configuration. The next time BIG-IQ deploys a configuration to that BIG-IP device, it updates the object to match the one on BIG-IQ.
- Use BIG-IP
- Use the object from the BIG-IP device's configuration to replace the object in the BIG-IQ system's working configuration that is different. If you select this option, BIG-IQ replaces that object for all of your managed BIG-IP devices the next time it deploys a configuration.
- Create Version
- BIG-IQ creates and stores a copy of the BIG-IP device's LTM monitor or profile object (s), specific to the software version running on that BIG-IP device. If you select this option, BIG-IQ replaces that object for all the managed BIG-IP devices running that version, the next time it deploys a configuration. You can store multiple versions of LTM monitors or profiles. BIG-IQ deploys the appropriate stored version to your managed devices. BIG-IQ automatically resolves conflicts against the appropriate version the next time it imports services that contain LTM monitors or profiles.
If you choose to resolve them all the same way, you can select from these conflict
resolution options.
- Use BIG-IQ
- Keep the object in BIG-IQ system's working configuration. The next time BIG-IQ deploys a configuration to that BIG-IP device, it updates the object to match the one on BIG-IQ.
- Use BIG-IP
- Use the object from the BIG-IP device's configuration to replace the object in the BIG-IQ system's working configuration that is different. If you select this option, BIG-IQ replaces that object for all of your managed BIG-IP devices the next time it deploys a configuration.
- Create Version
- BIG-IQ creates and stores a copy of the BIG-IP device's LTM monitor or profile object (s), specific to the software version running on that BIG-IP device. If you select this option, BIG-IQ replaces that object for all the managed BIG-IP devices running that version, the next time it deploys a configuration. You can store multiple versions of LTM monitors or profiles. BIG-IQ deploys the appropriate stored version to your managed devices. BIG-IQ automatically resolves conflicts against the appropriate version the next time it imports services that contain LTM monitors or profiles.
Editing the service configurations
After you have import the service configurations, you can use the
Configuration screens to review and edit them before deploying them back to your managed
BIG-IP devices. Essentially, you are modifying the configurations to stage them for
deployment back to the BIG-IP devices. You will probably spend most of your time in this
part of the process, since there are potentially many configuration settings that you
will want to review.
When reviewing the configurations:
- Be aware of dependencies between configurations. For example, your changes to the Network Security configuration settings might require that you make changes to the Local Traffic settings.
- Be aware of the version of the BIG-IP devices to which you are going to deploy the configuration. Different versions of BIG-IP might require different settings or values.
- If needed, refer to the documentation or online help for clarification about which settings are valid.
Changes you make to the configuration on the BIG-IQ system are not immediately deployed to the
BIG-IP devices, but are staged as part of the BIG-IQ working configuration. The
exception to this staging, is in the Local Traffic service, where you can use the
Change Now
setting to more quickly enable or disable virtual
servers or pool members, when needed.Evaluating and reviewing configuration differences
You evaluate your working configuration changes before you attempt to
deploy them to your BIG-IP devices using the screens found at
. Evaluating your working configuration changes allows you to review and
fix any potential problems before you deploy the configuration. When you perform an evaluation, it compares the working configuration
on the BIG-IQ system to the configuration running on the BIG-IP device, and then
displays the differences for you to review. Differences can be caused by changes made to
the configuration on the BIG-IQ system, or by changes made directly to the configuration
on the BIG-IP device without using the BIG-IQ system. You can create an evaluation for
one or for multiple BIG-IP devices.
This is a summary of what happens during the evaluation process.
- When you begin the evaluation process, the BIG-IQ system captures the current service configuration on the BIG-IP device, creates a snapshot of the BIG-IQ working configuration, and then compares the two configurations for that device.
- You now can review the configuration differences using a graphical summary of the differences. You can also view the JSON code differences for each object that has been modified, added, or removed.
- After reviewing the differences, you take one of these actions:
- If you are satisfied with the evaluation results, proceed with deploying the BIG-IQ working configuration to the BIG-IP device.
- If you are not satisfied with the evaluation results, make whatever changes are needed on the BIG-IQ working configuration, and evaluate the configurations again. If you want to keep changes that were made directly on the BIG-IP device, re-import the BIG-IP device configuration, and evaluate the configuration again.
Keep the following considerations in mind when performing
evaluations:
- If there are changes to the Local Traffic service configuration, you should evaluate that working configuration first, since any changes you need to make there could affect other configurations.
- You can use the evaluation process to review not only working configuration changes, but also changes in a configuration you captured in a snapshot.
- You can also evaluate and deploy a selected set of objects rather than an entire configuration. This is sometimes referred to as apartial deployment.
Deploying the configurations
When you have successfully evaluated your configurations, you can then
deploy them to the devices. You can
schedule the deployment to occur at a later time, when your systems are not busy, and
the deployment can be performed by another user with the appropriate deployment role if
necessary. You might even want to have someone else review the configuration before it
is deployed, to avoid issues.
When you deploy the
configuration, it makes the BIG-IP configuration look exactly like what is on BIG-IQ,
including overwriting changes that were made directly to the BIG-IP device or deleting
items that were created directly on the BIG-IP device. The BIG-IQ configuration that is
deployed is the same for all the BIG-IP devices managed. This idea of a single
configuration being the same for multiple devices is sometimes referred to as the BIG-IQ
configuration being the
source of truth
for all the
managed BIG-IP devices. You can perform a deployment immediately or you can schedule it
to occur later.If there are changes to the Local Traffic service configuration, you should
deploy that configuration before any other configuration, since the Local Traffic
service configuration can affect the other configurations.
If only a few changes were made to the configuration, you might be able to
perform a partial deployment. Partial deployments typically complete more quickly than
full deployments since only some of the configuration is being deployed. You use the
screens at
to perform deployments.The BIG-IQ system deploys all configuration changes to the BIG-IP device
using the REST API. Once the deployment is complete, you can review the deployment job
to see what changes were deployed. An object-by-object difference view in JSON format is
available as well.
Considerations when managing BIG-IP devices
You should consider these facts when managing your devices using Centralized Management.
- Avoid making configuration changes directly on a BIG-IP device that is managed by the BIG-IQ Centralized Management system.If you make changes locally on the BIG-IP device, you must re-import the configuration to reconcile those changes with the BIG-IQ Centralized Management working configuration. If you do not re-import the configuration, a subsequent deployment of the configuration from the BIG-IQ Centralized Management system will overwrite your local changes on the BIG-IP device.
- Be aware of the BIG-IP device versions and features supported by your version of BIG-IQ Centralized Management. BIG-IQ Centralized Management tracks the BIG-IP device versions and can act based on the version. For example, in BIG-IQ Centralized Management, a feature that is only supported for BIG-IP devices version 13.0 or later might not appear as an option to be managed for an earlier version of a BIG-IP device.You can find compatibility information in theBIG-IQ Centralized Management compatibility matrixon the F5 support web site, support.f5.com. In addition, review the BIG-IQ Centralized Management service documentation, since some features might be supported only with certain versions of BIG-IP devices.
What is an application and how do I create one?
An application is just a container that houses multiple application
services in the BIG-IQ user interface. There are a number of different application types you
can create depending on what you plan to do with it. The work flow for creating each type
varies a little.
- An application is a collection of application services that all work to support a common business process. By combining these into one container, you can manage all of the services required to operate that process from one place in the BIG-IQ user interface.
- A multi-cloud, or multi-site application distributes multiple versions of a common application service across different physical locations or cloud platforms. With versions hosted on different platforms or locations, your availability improves, and the overall application health is more robust. If one data center or cloud platform goes down, application traffic just flows to the other one. Or, you might just want the performance benefits that can come from processing traffic locally.
Standard Application
The basic work flow for creating a standard application is to:
- Create a new application. This creates the 'container' along with a single application service.
- Add each of the application services needed to perform the business process you need to support.
Once all of the services are live, you can track their aggregate health
and performance; or, you can drill down to track the performance of each application
service.
Multi-Cloud Application
The basic work flow for creating a multi-cloud application is to:
- Create or modify an AS3 or service template that defines the objects you need in your application service.
- Create the application that will house your application services.
- Use the template to deploy an application service to one cloud provider or data center.
- Use the template to deploy the same application service to a second cloud provider or data center.
- Use a template to create a DNS application service that load balances the traffic between the two application services.
If one cloud platform or data center experiences performance issues,
traffic automatically routes to the other platform, so your application continues to
perform.
Overview of other common BIG-IQ tasks and concepts
You use the essential Centralized Management features when you add a device to the BIG-IQ system, and manage the service
configurations on that BIG-IP device.
There are other features and concepts that you will commonly use
managing your configurations, such as:
- Re-discovering and re-importing configurations when you encounter configuration problems.
- Capturing and restoring snapshots of configurations so you can roll back to a previous set of changes.
- Reviewing audit logs to see what changes have been made on the BIG-IQ system, and by whom.
- Recognizing the difference between device-specific and shared objects, particularly when doing deployments.
- Using device configuration templates to simplify device configuration.
Re-discovering or re-importing configurations when needed
Typically, once configurations are imported, there is no need to
re-import or re-discover a BIG-IP device. However, you might need to do so in the
following cases:
- If you added, changed, or deleted management IP addresses or virtual servers directly on the BIG-IP device.
- If you made changes to other parts of the configuration locally on the BIG-IP device, without using BIG-IQ Centralized Management.
- If you made updates to the BIG-IP device software that need to be recognized by the BIG-IQ Centralized Management system.
If any of these events occurred, you must re-import and re-discover
the configuration to synchronize those changes with the configuration maintained on the
BIG-IQ system. If you do not reconcile changes, a subsequent deployment will overwrite
the changes made locally on the BIG-IP device. You re-discover and re-import a
configuration using the screens found here,
.Capturing and restoring configurations using snapshots
You can capture the working configuration on the Centralized Management system using snapshots. Once
created, snapshots can be compared to other snapshots or to the working configuration on
the BIG-IQ system. You can also deploy a snapshot if needed.
If you need to roll back a change that was made to the device, you can perform an evaluation
operation that compares the configuration on the BIG-IP device to a snapshot, and then
deploys the snapshot to the BIG-IP device. Rolling back changes in this manner is easier
and more reliable than editing the configuration to return it to a previous state.
Snapshots can also be used to correct errors in the BIG-IQ working configuration, if an
error is made there.
- To evaluate and deploy a snapshot to a BIG-IP device, you use the screens at.
- To create and compare snapshots, you use the screens at.
- To restore the BIG-IQ working configuration to a snapshot configuration, you use the screens at.
Reviewing BIG-IQ system changes using audit logs
You can use the BIG-IQ Centralized Management audit logs to view
changes on the BIG-IQ system. The audit log contains information on which user account
made the change, when they made the change, and other related information.
You can review audit log entries and search the audit log entries for
changes using the system interface. Changes are shown as highlighted differences between
JSON files. You use the screens at
to view audit logs for each of the services, such as Network Security or
Local Traffic and Network. The Monitoring screens contain many other useful tools for
understanding what is occurring on your BIG-IQ system.How do shared objects impact my deployments?
The objects that you manage using BIG-IQ depend on associations with
other, supporting objects. These supporting objects are called
shared
objects
. When the BIG-IQ evaluates a deployment to a managed device, it starts by
deploying the device-specific objects. Then it examines the managed device to compile a
list of the objects that are needed by other objects on that device. Then (based on the
recent analysis) the BIG-IQ deletes any shared objects that exist on the managed device but
are not used. So, if there are objects on a managed device that are not being used, the next
time you deploy changes to that device, BIG-IQ deletes the unused objects.About configuration templates
BIG-IQ® can manage multiple devices simultaneously. These devices can be
located in several data centers that may be located in many different locations. To help you
easily manage required configuration changes to DNS, NTP, SMTP, and Syslog for a large number of
devices, you can use configuration templates.
To start, you create a configuration template, then deploy that template to certain
devices. This can save a significant amount of time because you are not required to log in to
each device individually to make configuration changes.