Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Administrative Partitions
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

An important part of managing the BIG-IP® system is configuring the extent to which other BIG-IP system users can access various system objects. Access in this case refers to performing cerrtain actions, such as creating, viewing, modifying, and deleting system objects. Examples of system objects that users might want to access are virtual servers, load balancing pools, health monitors, nodes, and user accounts.
If you have the Administrator or User Manager user role assigned to your BIG-IP system user account, you can control other users access to objects by using a feature known as administrative partitions. An administrative partition is a logical container that you create, containing a defined set of BIG-IP system objects. When a specific set of objects resides in a partition, you can then give certain users the authority to view and manage the objects in that partition only, rather than to all objects on the BIG-IP system. This gives a finer granularity of administrative control.
A significant benefit to administrative partitions is that they allow you to place administrative ownership of an application into the hands of the business units that actually run the applications.
Figure 3.1 shows an example of partitions that you can create on a BIG-IP system. Partition App1 contains objects that pertain to an HTTP application, partition App2 contains objects that pertain to traffic utilizing Packet Velocity® ASIC (PVA), and partition Users contains local user accounts on the BIG-IP system.
Many types of BIG-IP system objects, such as profiles and pools, reside in administrative partitions. When BIG-IP system objects reside in partitions, you have better administrative control over those objects, because you can limit user access to specific partitions, and therefore to specific objects.
The complete list of object types that reside in partitions is shown in Table 3.1. Note that any object types not listed in this table (for example, VLANs and self IP addresses) cannot reside in partitions.
User accounts
Virtual servers
Pools
Pool members
Nodes
Custom profiles*
Custom monitors
iRulesTM
* This includes any configuration objects and server objects that are associated with authentication profiles.
Distributed Applications
Wide IPs
Pools
Pool members
Monitors
During BIG-IP system installation, the system automatically creates a partition known as partition Common (often referred to as the Common partition). This partition contains all of the BIG-IP system objects that the system creates during installation. Specifically, these are:
The root, admin, and support user accounts
Important: Until you create other partitions on the system, all objects that you or other users create automatically reside in partition Common. If you create other partitions later, you cannot move an object in Common to one of the new partitions. Instead, you must delete the object from Common and recreate it in the new partition.
With respect to permissions, all users on the system except those with a user role of No Access have read access to objects in the Common partition, and by default, the Common partition is their current partition. (For information on the current partition, see The current partition, following.)
Some users, such as those with the user role of Administrator, can also create, update, and delete objects in the Common partition. No user can delete the Common partition itself. For information on the permissions of each user role with respect to viewing and managing objects in partition Common, see Chapter 4, Managing User Accounts.
The current partition is the specific partition to which a logged-in user currently has access, as determined by the properties of that users account. Whenever a user performs an action on the BIG-IP system, the system automatically performs that action within the current partition.
As described in Chapter 4, Managing User Accounts, a user account grants permission to access either a single partition (other than partition Common) or all partitions. If a user has permission to access one partition only, the user cannot select the current partition. Instead, the BIG-IP system establishes the users current partition at login time, based on the particular partition access that is specified in the properties of that user account.
Users who have permission to access all partitions can actively select the current partition, that is, the specific partition they want to view or manage.
For example, suppose user rsmith has a role of Manager, and a user with an Administrator role has given user rsmith access to all partitions on the system (for example, partitions A, B, C, and Common). In this case, before creating or managing any object on the BIG-IP system, user rsmith must select the partition (A, B, or C) that she wants to be the current partition. After selecting the current partition, any object that she creates will reside in that partition, and she can modify or delete only those objects that reside in the current partition. If she fails to select partition A, B, or C, the current partition is Common, by default.
Conversely, if user rsmith has the role of Manager and she is granted access to partition A only, then any object that she creates while logged into the BIG-IP system automatically becomes a member of partition A. Although she can view objects in partition Common, she cannot select Common as her current partition because she has read access only for that partition. For user rsmith, partition A is automatically her current partition, and she cannot change the current partition to create objects in another partition.
Certain BIG-IP system objects, such as virtual servers, always reference other objects. Examples of objects that a virtual server can reference are pools, profiles, and iRules. When you create objects, a referenced object must reside either in the same partition as the object that is referencing it, or in the Common partition.
For example, if a virtual server such as my_vs resides in partition my_app and references the pool my_pool, then the object my_pool must reside either in partition my_app or in partition Common.
Figure 3.2 shows an example of an allowed configuration, where a virtual server and the pool it references reside in the same partition (partition my_app).
The other case in which one object can reference another is when the object resides in one partition, while the object it references resides in partition Common. Figure 3.3 shows an example of this configuration, where a virtual server in partition my_app references a pool in partition Common.
Note in this illustration that direction is important; the referencing object (the virtual server) must be in a user-created partition (my_app), while the referenced object (the pool) must reside in partition Common. As shown in figure 3.4, the virtual server cannot reside in partition Common and reference a pool that resides in partition my_app.
Assign partition access to user accounts
You can assign an authorized partition (known as partition access) to a user account. A partition access assignment gives a user some level of authority over the specified partition. As an option, for all user roles you can assign universal access to partitions, which grants users permission to access all partitions instead of one non-Common partition only. Note that assigning partition access to a user does not make the user a member of that partition, nor does it necessarily give the user full access to all objects in the partition.
Create user accounts as partitioned objects
As described earlier, when you create a user account, you assign partition access for that account as a way to define the scope of that users access control. However, like many other object types, user accounts also reside in partitions. This controls other users administrative access to those user accounts. Also like other object types, a BIG-IP system user account cannot belong to more than one partition simultaneously. Note that when you first install the BIG-IP system, every existing user account (root, admin, and support) belongs to partition Common.
To see the relationship of partitions to objects, consider the following example. This example shows how you can configure the BIG-IP system to grant a particular BIG-IP system administrator, Jane Smith, permission to manage all objects in a specific partition pertaining to the management of HTTP traffic. Note that to perform this task successfully, your own user account must have the role of Administrator assigned to it.
2.
Select the vendor_appl partition to be the current partition.
3.
Create any HTTP-related objects that you want to reside in that partition, such as a virtual server, a load balancing pool, and an HTTP profile.
4.
Select an existing partition in which you want Janes user account to reside, such as IT_users.
This is now your current partition.
a)
Assign the name jsmith to the user account.
Note that this account resides in the current partition, IT_users.
b)
Create a password for the jsmith user account.
c)
Assign the user role of Manager to the jsmith account.
This role allows Jane to control all resources in the partition to which she is given access (see the following step).
d)
Designate the vendor_appl partition as the partition to which user jsmith has access.
When Jane logs into the system as jsmith, the system sets her current partition to vendor_appl because this is the partition you assigned to her when you created her user account (see step 5d). Because you assigned her a user role of Manager, Jane can fully manage all objects in partition vendor_appl, as well as create new objects. Note, however, that the user account object jsmith resides in partition IT_users.
Important: As shown in this example, there is no relation between the partition in which the jsmith user account resides (IT_users) and the partition to which the jsmith account has access (vendor_appl).
When implementing the partitions feature, there are some specific aspects of the feature that you should consider, with corresponding recommendations. See Table 3.2 for more information.
An object can only reference another object if both objects are in the same partition, or if the referenced object is in partition Common.
When you create objects, ensure that the referencing object and its referenced object reside in the same partition, or that the referenced object resides in partition Common.
If you want to change the partition in which an object resides, delete the object from the old partition, and recreate the object in the new partition.
Note that if the object you want to delete and recreate in another partition is a pool that resides in partition Common, you should not only delete the pool, but also delete any nodes associated with that pool. Otherwise, pools in other partitions can reference those nodes that are in partition Common.
The same BIG-IP system object cannot be a member of more than one partition simultaneously.
If an authorized user modifies a parent object, the system propagates the changes to all child objects, regardless of the partition in which the child object resides.
Be aware that modifications to a child object that other administrators implemented might appear.
If a user with permission to manage objects in partition Common disables a monitor that is designated as the default monitor for nodes (such as the icmp monitor), this affects all nodes on the system.
An iRule can reference any object, regardless of the partition in which the referenced object resides. For example, an iRule that resides in partition A can contain a pool statement that specifies a pool residing in partition B.
For objects that cannot reside in partitions (such as VLANs, self IP addreseses, and packet filters), only users with the Administrator or Resource Administrator role have full access to these objects. Users with a role other than Administrator, Resource Administrator, or No Access can view these objects, but they cannot create, modify, or delete them.
When attempting to create an object, the user might see an error message stating that the object already exists, even though the object name does not appear on the list screen. This is because the existing object resides in a partition that the user has no permission to access.
Every object on the system must have a unique name, regardless of the partition in which the object resides.Therefore, when creating an object on the system, be sure to assign a unique name to the object.
If your BIG-IP system implementation includes the Global Traffic Manager, it is likely that you want to divide your Global Traffic Manager objects, such as distributed applications and wide IPs, into separate partitions. However, before you assign Global Traffic Manager objects to partitions, there are several factors that you must first consider, as partitions affect the Global Traffic Manager differently from the way they affect the Local Traffic Manager.
This section describes the types of objects you can partition within a Global Traffic Manager context, and explains the additional considerations you must make before assigning these objects to partitions.
As is true with the Local Traffic Manager, not all objects in the Global Traffic Manager are partitioned. The following is a list of objects that you can partition within the Global Traffic Manager:
In addition to the objects described in this list, you can assign listeners and Global Traffic Manager iRules to partitions, although this is not recommended. These two objects are responsible for handling how the Global Traffic Manager responds to network traffic. Consequently, assigning these objects to one or more partitions does not affect Global Traffic Manager behavior; in fact, these objects remain visible to all users.
Unlike their equivalent in the Local Traffic Manager, virtual servers in a Global Traffic Manager context are not partitioned. Remember that virtual servers in a Global Traffic Manager often refer to IP addresses and port numbers managed by local load balancing devices. Consequently, the role they play in your network management differs from the virtual servers you create on a system such as a Local Traffic Manager.
If you are familiar with the Gloabl Traffic Manager, you are aware that you can create synchronization groups, which consist of several Global Traffic Managers. With synchronization groups, the change you make on one Global Traffic Manager immediately propogates to the other Global Traffic Managers in that synchronization group.
When you create a synchronization group, the Global Traffic Managers in that group synchronize a partition only if that partition contains a Global Traffic Manager object. In addition, the synchronization event applies only to Global Traffic Manager objects in a given partition; other objects are ignored.
To illustrate this, consider the fictional company SiteRequest. At SiteRequest, two partitions are created on a Global Traffic Manager/Local Traffic Manager combination box: partition Alpha, which contains Local Traffic Manager objects and Global Traffic Manager objects, and partition Beta, which contains only Local Traffic Manager objects. After the next synchronization event occurs with the other Global Traffic Manager systems on the network, each system contains partition Alpha, but only with the Global Traffic Manager objects. The Local Traffic Manager objects that exist in partition Alpha are not created on the other Global Traffic Manager systems. Partition Beta, which contains only Local Traffic Manager objects, is not created at all.
It is also important to remember that the user accounts that determine who has access to a given partition are not part of the synchronization process. Consequently, when you create new user accounts to access your partitions, you must manually re-create those accounts on any other Global Traffic Manager system on your network.
Set the current partition
Note that you cannot move a BIG-IP system object from one partition to another. If you need to change the partition in which an object resides, you must delete the object from the old partition and recreate the object in the new partition.
Important: To create, modify, or delete a partition, or view the properties of a partition, you must have the Administrator role assigned to your user account. Users with other user roles might have permission to manage the objects within a partition, but only users with the Administrator role can manage partition objects themselves.
Setting the current partition
When you log in to the BIG-IP system, the system automatically establishes the current partition, based on the partition access assigned to your user account. Users with universal partition access (that is, access to all partitions) can change the current partition. Changing the current partition is required if you want to manage BIG-IP system objects that are not in the current partition, or if you want to create objects in a partition other than the current partition.
For example, if the current partition is partition B, but you want to add a virtual server to partition C, you must change the current partition from B to C before you create the virtual server. Note that if a user with the Administrator role chooses to do so, he can grant universal partition access to any user account with a role other than No Access.
You set the current partition by selecting a partition name from the list box in the upper-right corner of any Configuration utility screen. Figure 3.5 shows this list box.
Figure 3.5 List box for setting the current partition
To set the current partition
1.
Log in to the Configuration utility.
The default Configuration utility screen opens.
2.
From the Partition box in the upper right corner of the screen, select the partition name that you want to become the current partition.
From this point on, any objects you create will reside in this partition, and the only objects you can modify or delete are those that reside in this partition.
Note: If the Partition box in the upper right corner of the Configuration utility is displayed but unavailable, you do not have a user role that grants you permission to change the current partition. In this case, contact the BIG-IP system administrator who created your user account.
Before you can put BIG-IP system objects into a partition, you must create that partition. You can create a partition using the Configuration utility. Only users with the Administrator or Resource Administrator user role can create partitions.
1.
On the main tab of the navigation pane, expand System, and click Users.
The Users screen opens.
2.
On the menu bar, click Partition List.
This displays the list of partitions that you are allowed to view. User accounts with the Administrator or Resource Administrator role can view all partitions on the system.
Note: If the Create button is unavailable, you do not have permission to create a partition. You must have the Administrator or Resource Administrator role assigned to your user account.
4.
In the Name box, type a unique name for the partition.
5.
In the Description box, type a description of the partition, for example, This partition contains local traffic management objects for managing a vendor application.
6.
Click Finished.
Note: If you are looking for a specific partition name and it does not appear in the list, you do not have a user role that grants you permission to view or access that partition.
1.
On the main tab of the navigation pane, expand System, and click Users,
The Users screen opens.
2.
On the menu bar, click Partition List.
This displays the list of partitions that you are allowed to view.
The name of the partition
Once configured, you cannot modify this property.
A textual description of the partition
You can modify this property at any time, if you have permission to do so.
All users have permission to view the properties of a partition. Users with the Administrator or Manager role can not only view the properties, but also modify the partition description. To either view or modify a partition property, you can use the Configuration utility.
1.
On the main tab of the navigation pane, expand System, and click Users,
The Users screen opens.
2.
On the menu bar, click Partition List.
This displays the list of partitions for which you are allowed to view properties.
3.
In the Name column, click the name of an existing partition. This displays the properties of the partition, that is, the name and description.
4.
There are two ways to delete a partition using the Configuration utility. You can either list the existing partitions and mark a partition in the list for deletion, or you can display the properties of a partition and use the Delete button.
Tip: You cannot delete a partition that contains objects. Therefore, prior to deleting a partition, delete any objects that reside in the partition.
1.
On the main tab of the navigation pane, expand System, and click Users.
The Users screen opens.
2.
On the menu bar, click Partition List.
This displays the list of partitions that you are allowed to delete.
5.
Click Delete.
A confirmation box appears.
6.
Click Delete.
1.
On the main tab of the navigation pane, expand System, and click Users.
The Users screen opens.
2.
On the menu bar, click Partition List.
This displays the list of partitions that you are allowed to delete.
3.
In the Name column, click the name of an existing partition. This displays the properties of the partition, that is, the name and description.
4.
Click Delete.
A confirmation box appears.
5.
Click Delete.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)