Professional Documents
Culture Documents
Datapower Redbook
Datapower Redbook
Network Configuration,
Monitoring, and Logging
Gerry Kaplan
Ronnie Mitra
Jan Bechtold
Helio L. P. Mota
David Shute
Daniel Dickerson
Richard Kinard
John Walczyk
ibm.com/redbooks
Draft Document for Review April 13, 2011 6:45 am 7901edno.fm
April 2011
SG24-7901-00
7901edno.fm Draft Document for Review April 13, 2011 6:45 am
Note: Before using this information and the product it supports, read the information in
“Notices” on page xi.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The team who wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . xv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Chapter 2. Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1 Network interface configuration and routing . . . . . . . . . . . . . . . . . . . 31
2.3.2 VLAN sub-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.3 Network settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.4 Host alias, static hosts, and DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.5 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3.6 Load balancing a backend destination . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.7 Intelligent Load Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.8 Self-Balancing services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.9 Load Balancer health checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.10 Standby Control and high availability . . . . . . . . . . . . . . . . . . . . . . . 45
2.4 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.1 Avoid using 0.0.0.0 as a listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.2 Separating management traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.3 Specify port values less than 10,000 . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.4 Persistent timeout consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.5 Disable chained persistent connections . . . . . . . . . . . . . . . . . . . . . . 47
2.4.6 Configure network settings to be portable. . . . . . . . . . . . . . . . . . . . . 47
2.4.7 Multiple default gateways will create multiple default routes. . . . . . . 48
2.4.8 Standby Control best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.9 Management interface and default route . . . . . . . . . . . . . . . . . . . . . 50
2.4.10 Enabling “No Delay Ack” to avoid latency with other systems . . . . 50
2.4.11 Streaming large messages and flow control . . . . . . . . . . . . . . . . . . 51
2.5 Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.5.1 Externalizing endpoints in a Meta Data document . . . . . . . . . . . . . . 52
2.5.2 Disabling chained persistent connections for various different points of
a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.5.3 Port speed mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.5.4 Sample DNS workaround using static host . . . . . . . . . . . . . . . . . . . . 54
2.5.5 Sample CLI commands to capture DNS server responses. . . . . . . . 54
2.5.6 Sample test to see if Rapid Spanning Tree has been deployed properly
for DataPower Standby Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.5.7 Example of deleting routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5.8 Sample XSLT for adding DataPower transaction ID to an HTTP header
for outgoing traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 3. Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1 Application domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.1.1 The default domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.1.2 Domain use and benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.1.3 Segregating projects and LOBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.4 Number of domains on an appliance . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.5 Domain resource consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2 Domain structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.1 Local flash-based file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.2 Domain configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.3 Domain logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.4 Domain monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Contents v
7901TOC.fm Draft Document for Review April 13, 2011 6:45 am
Contents vii
7901TOC.fm Draft Document for Review April 13, 2011 6:45 am
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Contents ix
7901TOC.fm Draft Document for Review April 13, 2011 6:45 am
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. These and other IBM trademarked
terms are marked on their first occurrence in this information with the appropriate symbol (® or ™),
indicating US registered or common law trademarks owned by IBM at the time this information was
published. Such trademarks may also be registered or common law trademarks in other countries. A current
list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
Preface
This IBM® Redbooks® publication is part of a two volume set that focuses on
operational and managerial aspects, as well as best practices for DataPower®
appliance deployments.
The following authors also contributed to the content and creation of this book.
Debbie Willmschen
Stephen Smith
Linda Robinson
Tamikia Barrow
Shari Deiana
International Technical Support Organization, Raleigh Center
Preface xv
7901pref.fm Draft Document for Review April 13, 2011 6:45 am
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
Preface xvii
7901pref.fm Draft Document for Review April 13, 2011 6:45 am
The topic of access control on its own is a broad topic, especially when put in
context with the diverse ways in which organizations secure data centers and
lock down network infrastructures. Although this chapter cannot provide patterns
for every possible scenario, it does provide a strong foundational and technical
understanding of how the building blocks of DataPower administrative security
works.
1.1 Overview
DataPower appliances perform a broad range of functions and often act as the
gatekeeper or governor of business critical data flowing in to, out of, and within
an enterprise’s network. The appliance can contain not only processing policies
that prepare and forward messages to other systems, but it can also contain
highly guarded key material. For this reason, it is both important and essential to
control access to DataPower appliances.
Organizations that deploy DataPower appliances find that the audience of users
who need access frequently crosses departmental boundaries. Network
administrators require access to perform network-related configuration tasks,
such as IP address assignment and route definitions, while development teams
require access to configure processing policies and message flows. This
separation of concerns adds a level of complexity not normally encountered on
simple network devices. Developers should be prevented from accessing base
appliance configuration details, while network personnel should be restricted to
only network-related functions. The DataPower Role-Based Management (RBM)
subsystem handles these administrative requirements, allowing for access
policies to be as broad or fine-grained as necessary.
1.2 Benefits
A well thought-out plan for securing and administering DataPower appliances
can provide the following benefits:
Prevent unauthorized access to an appliance, reducing the risk of malicious
threats from both inside and outside the organization.
Prevent accidental or malicious intentional modification to network, appliance,
and policy configurations.
Provide a clear separation of roles and responsibilities. Network
administrators, developers, and lines of business can be clearly defined and
administered independently.
Assure the integrity of the network environment.
During the first-time boot, the operator performs several essential key steps:
Accept the End User License Agreement.
Most of the steps result in configuring network access and are relatively
straightforward; however, two of these steps require special attention:
Setting the administrator’s password
Deciding whether to enable disaster recovery
Due to the hardened secure nature of the appliance, should administrator access
becomes impossible as a result of misplaced passwords, the appliance must be
returned to IBM for complete reinitialization.
Note regarding private key material: Private key material is encrypted within
the backup and can be decrypted only by another DataPower appliance.
Disaster Recovery Mode can be set only during the first-time configuration.
When set, it can be changed only by reinitializing the appliance back to its initial
factory condition.
Important: Disaster Recovery Mode cannot be changed after the initial setup.
Note: ACLs control only which IP addresses can connect to the appliance;
authentication and authorization of the user still occurs.
ACLs are set up in the associated service configuration page. For example, the
web-mgmt ACL can be found on the Web Management Service configuration page
(Network Management Web Management Service).
Take care when setting up ACLs, because it is possible to become locked out of
the appliance. ACLs should not contain DHCP assigned IP addresses because
these addresses can change unexpectedly. In the event of ACL lock-out, access
can be restored from a terminal connected to the serial port.
A user’s access level determines whether access privileges are managed by the
DataPower RBM subsystem. Table 1-1 shows the available access levels and
their descriptions.
User Grants access only to system status functions. This access level
is the most limited type of user and does not use RBM.
Group-defined Assigns the user to a local user group. User groups define a set of
access rights to resources and functions. The user inherits the
rights of their assigned group, which we discuss in more detail
later in this section.
access to the device and should be used sparingly if at all. Privileged users are
effectively administrators.
Note: Group-defined access level is the preferred method for defining access
privileges. Avoid using user and privileged access levels if possible.
Figure 1-1 shows the relationship between a group, users, and a resource on a
typical Linux server.
owner
User1
Permissions
Group: editors
Owner: User1, RWX
Group: editors, RW
Others: R
User2 User3 User4
Uncategorized Users
Legends:
R = Read
W = Write
User5 User6 X = Execute
In contrast, a DataPower user group acts more like an organizational role; the
group defines a set privileges to resources and device functionality. For example,
one user group can define privileges for a user administrator, while another group
defines privileges for a network administrator or developer.
Figure 1-2 depicts the DataPower user and user group relationship.
User: User2
Group: developer
User Group: developer
Access Profile
Permission to use certificate mgmt functions
Permission to configure services
Permission to read Xform.xsl
User: User3 Permission to create objects in domain1
Group: developer
Figure 1-2 DataPower user groups are used to define administrative roles
Access profile
The user group defines resource access privileges using an access profile. After
a user is authenticated, their credentials are determined by inspecting the access
profile from the user’s assigned group and mapping each permission into a
credential. For example, in Figure 1-2, user User1 has an assigned user group of
useradmin. Therefore, after authentication user User1 will have credentials that
grant permission to perform user and certificate management tasks.
resource Identifies the type of the resource to which the statement is applied.
Specifying an asterisk (*) indicates that this policy should apply to
all resources.
Add’l fields Depending on the resource type, additional fields can be specified
using a PCRE. For example, in the case of securing a file, a Name
parameter can be specified such as Name=Foo*, representing all files
beginning with Foo.
Explicitly denying access to the user is through the use of the keyword NONE
such as */*/*/services/xmlfirewall?Access=NONE. This statement denies any
type of access to any firewall in any domain on any device.
Example 1-4 shows an access policy that allows read only access to files whose
name starts with Foo within mydomain and only accessible through IP address
10.1.3.55.
Example 1-4 Access policy with IP, domain, and resource restrictions
10.1.3.55/mydomain/file/local?Name=Foo*&Access=r
Host names can be used instead of IP addresses. Example 1-5 shows an access
policy that allows the user to execute the change-password function but only
through the IP address defined as MgmtInt.
Example 1-5 Access policy protecting change password function using host alias
MgmtInt/*/access/change-password?Access=x
Note: Each value is a PCRE. Do not forget to frame your match expression
with ^ and $ if your intend is an exact match.
RBM controls access through both the WebGUI and SOMA. Login privilege to
either one can be granted separately. Example 1-6 shows an access policy that
grants login to web-mgmt only.
Example 1-6 Policy statement that grants access to login for web-mgmt only.
*/*/login/web-mgmt&Access=x
Example 1-8 gives a user read only access to any file within directories with
prefix someOtherPrefix_ and read/write access to any file with prefix
somePrefix_.
Example 1-8 Policy statements that limit access to files and directories
*/someDomain/file/local?&Directory=^someOtherPrefix_.*&Access=r
*/someDomain/file/local?&Directory=^someOtherPrefix_.*&Filename=^somePr
efix_.*&Access=r+w
Every configuration option and every resource can be protected using access
policy statements such as those shown in these examples.
The policy statement editor is available when creating or modifying a user group.
The Access Profile section has a Build button that opens the policy statement
editor. The smart editor provides drop-down lists of resource types and adjusts
the fields and options based on user selections.
Depending on which account type is selected, a user group can be created and
prepopulated with a number of access policy strings.
usergroup "account"
summary "Account Management"
access-policy */*/access/change-password?Access=x
access-policy */*/access/usergroup?Access=rwadx
access-policy */*/access/username?Access=rwadx
access-policy */*/access/username?AccessLevel=privileged&Access=NONE
access-policy */*/config/save-config?Access=x
access-policy */*/debug/set-loglevel?Access=x
access-policy */*/debug/set-rbmlog?Access=x
access-policy */*/login/ssh?Access=x
access-policy */*/login/telnet?Access=x
access-policy */*/login/web-mgmt?Access=x
exit
exit
A sample script for creating the roles shown in Figure 1-3 can be downloaded as
part of this book and is named createUserGroups.txt. Refer to Appendix B,
“Additional material” on page 247 for information on how to download the file. To
execute a CLI script like this, upload the file to the local: directory and use the CLI
exec command:
exec local:///createUserGroups.txt
In Example 1-10, the user name gkaplan is authenticated, and the credential is
useradmin.
Example 1-10 Sample RBM policy file for authentication and credential mapping
<AAAInfo xmlns="http://www.datapower.com/AAAInfo">
<Authenticate>
<Username>gkaplan</Username>
<Password>myPassw0rd</Password>
<OutputCredential>useradmin</OutputCredential>
</Authenticate>
<MapCredentials>
<InputCredential>useradmin</InputCredential>
<OutputCredential>
*/*/access/username?Access=rwad
*/*/access/usergroup?Access=rwad
*/*/status/object-status?Access=r
*/*/login/web-mgmt?Access=x
</OutputCredential>
</MapCredentials>
</AAAInfo>
User: User1
< MapCredentials>
Group: useradmin < InputCredential> useradmin< / InputCredent ial>
< Out put Credent ial>
*/ */ access/ username?Access= rwad
*/ */ access/ usergroup?Access= rwad
*/ */ status/ object- st at us?Access= r
*/ */ login/ web- mgmt ?Access= x
< / Output Credential>
User: User2 < / MapCredent ials>
Group: developer
< MapCredentials>
< InputCredential> developer< / Input Credential>
< Out put Credent ial>
*/ devdomain/ * ?Access= rwadx
< / Output Credential>
User: User3 < / MapCredent ials>
Group: developer
< MapCredentials>
< InputCredential> netadmin< / InputCredential>
< Out put Credent ial>
*/ */ access/ snmp?Access= rw
*/ */ config/ remove- chkpoint?Access= x
User: User4 */ */ config/ rollback- chkpoint?Access= x
Group: netadmin */ */ config/ save- chkpoint?Access= x
< / Out putCredential>
< / MapCredent ials>
Figure 1-4 Local user repository for authentication and an RBM policy file for credentials
Similarly, it is possible to use an RBM policy file for authentication and the local
group repository for credential mapping (see Figure 1-5 on page 17). The
<OutputCredential> from the authentication is used as the group name, and
RBM searches for that local group to extract the credentials from its access
profile.
Figure 1-5 Using an RBM policy file for authentication and local groups for credentials
The policy files are not centralized. RBM files can be published from one
device to another, but no real “user management” function exists to maintain
users and policies within the file.
Remote user management is a good idea but only provides half of the login
processing requirements. The user’s access credentials must still be determined.
There are a number of options that can be used to establish credentials for
remotely authenticated users:
A local user group
A Role-Based Management (RBM) policy file
A custom developed mapping solution written in XSL
Note: RBM only supports a user belonging to one group. If the results of an
LDAP query yield multiple groups, only the first returned group is recognized.
This limitation can be overcome using a custom stylesheet, as discussed in
“Custom credential mapping” on page 21.
Configuring the LDAP query to retrieve the user’s group is straightforward and is
accomplished by enabling Search LDAP for Group Name in the RBM Credentials
configuration page (Administration RBM Settings Credential tab). The
following configuration scenarios provide more details on using LDAP groups.
Using an LDAP organized as in Figure 1-6, the following events occur during
LDAP authentication and credential mapping:
1. RBM authenticates the user as previously described. The result of the LDAP
authentication is the user’s DN:
uid=hmota,ou=users,dc=ibm,dc=com
2. A second LDAP query is performed to discover to which group the user
belongs. RBM issues an LDAP query for group membership and requests the
cn attribute, which contains the group name. In this example, the cn attribute
value is developer.
3. RBM maps the value developer to a local group named developer and
obtains the user’s access profile.
<MapCredentials>
<InputCredential>uid=hmota,ou=users,dc=ibm,dc=com</InputCredential>
<OutputCredential>useradmin</OutputCredential>
</MapCredentials>
<MapCredentials>
<InputCredential>uid=jbechtold,ou=users,dc=ibm,dc=com</InputCredential>
<OutputCredential>useradmin</OutputCredential>
</MapCredentials>
<MapCredentials>
<InputCredential>useradmin</InputCredential>
<OutputCredential>
*/*/access/username?Access=rwad
*/*/access/usergroup?Access=rwad
*/*/status/object-status?Access=r
*/*/login/web-mgmt?Access=x
</OutputCredential>
</MapCredentials>
</AAAInfo>
</xsl:when>
<xsl:otherwise>
*/guestdomain/*?Access=r
</xsl:otherwise>
</xsl:choose>
</xsl:template>
Because the credential that is returned from the SSO authentication phase is the
DN of the peer’s certificate, it must undergo credential mapping. Credential
mapping happens much in the same way as described in 1.5.6, “Remote
authentication servers” on page 18:
An LDAP can be used to look up the user’s group membership, which can
then be mapped to a locally-defined user group (see “Local user group for
credential mapping” on page 19). The local user group provides the access
profile and credentials.
An LDAP can be used to look up the user’s group membership, which can
then be mapped to a set of access credentials in an RBM policy file (see
“LDAP group mapping” on page 21).
An RBM policy file can be used to look up the user’s access credentials (see
“Group mapping within the RBM policy file” on page 20).
Example 1-14 shows the CLI command to copy the audit log to a new file in the
temporary: directory.
Example 1-14 CLI command to copy audit log to the temporary: directory
copy audit:///audit-log temporary:///audit-log
Example 1-15 shows the CLI command to copy the audit log to an HTTP file
server URL.
Example 1-15 CLI command to copy audit log to an HTTP file server
copy audit:///audit-log <HTTP File Server-URL>
Example 1-16 shows the CLI command to send the audit log to a mail recipient
using an SMTP server.
Example 1-16 CLI command to send the audit log to a mail recipient.
send file audit:///audit-log <outgoing-mail-server> <email-address>
The SOMA response will contain the base64 encoded contents of the audit log
and therefore will require decoding.
1.8 Troubleshooting
Implementing administrative configurations that rely on remote authentication
servers, RBM policy files, or custom development might require a certain amount
of troubleshooting before all of the pieces are properly integrated. Care should be
taken to assure that the configuration steps do not inadvertently prevent access
to the appliance.
When testing or troubleshooting RBM, make sure to enable RBM debug
logging. This is found in the Troubleshooting panel in the Logging section. Log
messages might appear in either the regular system logs or the audit logs.
Verify that remote authentication servers are reachable from DataPower. Use
the Ping Remote and TCP Connection Test to assure the servers are
accessible.
Assure that any DNS server settings are properly configured.
Assure that the appliance’s time is accurate and that any NTP server
connections are working. Incorrect date settings could affect the validity of
some certificates.
Note: Make sure to always enable local users as fallback when making
changes to RBM and user management settings. This enables the users in the
local repository to remain active in the event remote authentication servers or
custom stylesheets fail to operate as expected.
Chapter 2. Networking
At their core, DataPower appliances are highly capable network device and
provide a wide array of networking, security, and integration tasks. Whether
protecting web services, mediating security tokens, or proxying between
disparate wire protocols, all activities rely in some fashion on the underlying
network. For this reason, it’s imperative that a DataPower appliance’s network
configuration be compatible with its surrounding network environment.
Understanding DataPower’s networking capabilities and configuration nuances
can help assure maximum processing throughput.
This chapter discusses the considerations and activities associated with IBM
WebSphere DataPower SOA Appliance Networking.
2.1 Overview
Due to the nature and scope of the appliance’s role in the network, networking
problems might be difficult to isolate and could possibly have a significant impact.
Understanding how to properly deploy the appliance on the network can help
prevent unexpected behavior and avoid future problems.
Demilitarized Demilitarized
Zone Zone
Legacy Internal
Enterprise Internet
User User
Application
Packet Filter
Packet Filter
Packet Filter
Packet Filter
SOA
Platform
SOAP
Enabled
Enterprise
Application Internet
Web Service
Enterprise
Application
2.2 Benefits
The DataPower appliance is highly configurable and the administrator should use
all of its features to achieve the desired network requirements.
2.3 Usage
This section describes the usage capabilities, configuration settings, and some of
the nuances regarding networking with the DataPower appliance.
Chapter 2. Networking 31
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
Ethernet interface
The device has four network interfaces and a serial port as shown in Figure 2-2
on page 32.
The network interface configuration screen for the DataPower appliance looks
like Figure 2-3.
Chapter 2. Networking 33
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
option to lease an IP address for the device is still available through the use of
the DHCP setting.
Default gateway
The default gateway defines the interface and route in which the traffic leaves
the appliance when it does not match an explicitly configured static route.
Secondary address
Each interface can have additional IP addresses in addition to the primary IP
address.
Note: The switch or router connected to the appliance interface must have
an exact port speed match.
If the port speed on the Ethernet interface is not set to the same port speed
as the connected switch, the following symptoms may occur:
– Slow performance in sending or receiving data.
– Inability to send or receive data (most commonly unable to send or receive
large amounts of data).
– Intermittent connectivity.
Static routes
it is possible to define the routing path of network traffic for each interface. Define
the routes carefully to avoid rule overlapping which can cause undesired
behavior.
When defining a static route, the following three fields must be set:
Destination - Defined using either CIDR or dotted decimal format.
Gateway - Should be the first hop on the network from the appliance.
Metric - A numeric value to determine priority (lowest value is used) when two
or more routes have the same destination.
Note: To find the first hop on the network from the appliance, issue a
traceroute command from the CLI Interface as depicted in Example 2-1 and
select the first entry.
Chapter 2. Networking 35
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
Note: The VLAN sub-interface can be configured to use DHCP, but then it will
not allow a static route to be defined for this sub-interface.
If static routes are defined within a VLAN sub-interface using DHCP, the VLAN
will drop the IP address and any connectivity to that IP address will be lost.
Chapter 2. Networking 37
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
link layer resets are seen on the network or to determine if this feature is
incompatible with the network traffic.
Reverse-Path Filtering
The option “Ignore packets with a source address that the interface cannot
route” can ignore packets that have a source address which the interface
cannot route.
By default, incoming packets with an unreachable source address will still be
accepted and processed.
Enable TCP Window Scaling
This setting allows negotiation of window sizes greater than 64 KB by default.
Disable this option when integrating with TCP systems that cannot handle
window scaling.
Host alias
The host alias may be used in place of IP addresses for object configuration and
are often used to simplify export and import of service configurations between
DataPower systems.
Static host
The static host setting manually maps a host name to the host IP address without
using DNS. This can be useful if DNS is not available, incorrect, or incomplete.
However, the device's DNS name resolver uses a cache, therefore static
mappings will usually not result in significant performance improvement.
If a port is not configured, the appliance uses port 53 by default (for both UDP
and TCP).
Chapter 2. Networking 39
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
Selecting the DNS Load Balancing Algorithm controls which DNS server is used
when multiple DNS Servers are configured.
There are two Load Balancing algorithms available for DNS servers:
The First Alive algorithm will use the first available DNS server in the list and
then will try subsequent servers in the list if the first DNS server is down.
When selected in the WEBGUI, the First Alive algorithm will show a retry and
timeout setting for the whole DNS group.
The Round Robin algorithm will alternate through the list of configured DNS
servers. Selecting the Round Robin algorithm only allows each DNS to have
its own retry setting.
2.3.5 Routing
The DataPower appliance has several features that affect the network path
selected for traffic. Packets responding to incoming traffic typically use the same
interface they came in on, however outgoing new TCP connections utilize the
routing table to select an outgoing interface.
The routing table shows the routing rules generated from configured static routes
and default routes.
A static route forces the DataPower appliance to use a specific interface and a
specific set of network hops to access a given set of destinations.
The default route is created by setting the Default Gateway on one of the
appliance’s interfaces. The appliance uses a default route when a given
destination address is unknown.
When a specific route cannot be found and multiple default routes are
configured, the appliance will randomly pick which interface to use for outbound
traffic.
For network traffic to follow a specific route, configure a static route instead of
relying on a Default Gateway.
Consider Example 2-2, which shows the routing table from the CLI command
show route:
The output shows three Default Gateways configured on eth0, eth1, and mgt0.
This causes three default routes to be generated as indicated by the 0.0.0.0/0.
If the destination address of the service is 10.10.10.100, the device will randomly
choose any one of the default routes because no specific route is configured. If
the appliance selects the mgt0 route using gateway 11.238.77.1 and the
gateway cannot route to the backend server IP address, this will trigger an
unexpected connection failure. This failure can be intermittent because the
appliance selects the route randomly.
Note: If using an external Load Balancer, the external Load Balancer should
be transparent to the appliance as a backend network destination endpoint.
Chapter 2. Networking 41
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
Caution: The Load Balancer Group Objects are not intended for usage in
static configuration settings such as the WSDL source location.
WebSphere Cluster
Cluster information
sent for load Deployment Mgr. with
balancing decisions. ODCInfo
Application Server 1
Application Server 2
DataPower
Client
Application Server 3
When Workload Management Retrieval is enabled and the Load Balancer Group
contains explicitly defined (static) members, the following rules apply:
If a member is part of the retrieved workload management information, its
configuration settings are updated dynamically.
If a member is not part of the retrieved workload management information,
the load balancer group disables this member. Although disabled and not
included in load balancing decisions, its configuration settings are not deleted
from the persisted configuration. Disabling the workload management feature
allows to display and update the information for these explicitly defined
members.
Chapter 2. Networking 43
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
Figure 2-6 on page 44 shows the request flow of two self-balanced requests.
Standby
Response 1
10.19.0.15
Request 1
Virtual IP – 10.19.0.1
Request 2
10.19.0.5
Response 2
Active
If the appliance acting as the distributor fails, another cluster member will
assume the role of the distributor and take ownership of the virtual IP address.
All of the DataPower appliances in the group are aware of all shared services.
Here are some types of health checks that might be used to detect whether a
service is available:
Basic requirements:
Must be on same network segment.
Must be configured with same VIP, group number, and authentication token.
A device may have only one instance of a particular standby group number.
Functionality:
Chapter 2. Networking 45
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
Using 0.0.0.0 as a listening address is typically not a good practice since this
will allow all interfaces to receive traffic for the assigned port. This may be an
unnecessary exposure when services are set to listen on this address.
The connection errors are associated with the inherent race condition that may
occur using an HTTP POST. This may cause the occurrence of a simultaneous
POST at one endpoint and a TCP close at the other end.
This method should be consolidated and not used across too many levels
whenever possible, as serialization/de-serialization will occur when passing
messages from one service to another.
Chapter 2. Networking 47
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
A general recommendation is to set specific static routes and use only one
default gateway that can catch all traffic not explicitly being directed by the static
routes. This may cause intermittent failure in connecting to other network
destinations. The default routes are generated when the default gateway is
configured on each interface.
Group number
An integer used to identify a standby group; allowable identifiers are in the range
1 through 255. All interfaces in a given standby group must have the same group
number. This value must be distinct from all group numbers being used by IP
routers or switches in the same broadcast domain.
The active interface in the group will change its ethernet MAC address to
00:00:0C:07:AC:XX, where XX is the group number. This number must also be
unique among all standby groups on a given system.
Configure the standby group number with a value higher than 20. This will help
avoid the accidental use of duplicate group numbers within a single network as it
is very common for network routers and switches to be configured with the lower
standby group numbers.
Virtual IP address
The IP address that will be used by the active member of the standby group.
External clients that want to be able to contact the active member of the standby
group should use this IP address. This address must be on the same IP subnet
as the primary address of the interface.
Make sure that Rapid Spanning Tree is properly deployed and that the
convergence time on the switch is less than the “hold” time configured on the
appliance. The default “hold” time on the appliance is 10 seconds. This should
help allow the proper amount of time to complete a failover and help prevent
unnecessary fail-overs caused by misconfiguration.
If the Rapid Spanning Tree is properly deployed and the convergence time
requires longer than 10 seconds, the “hello” and “hold” time intervals on the
appliance to accommodate the switch can be changed by using the standby CLI
command.
For example, issue the command shown in Example 2-3 from the CLI, where 100
is the group number, 5 is the hello time, and 15 is the hold time.
Chapter 2. Networking 49
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
As a general rule, the management interface should not have the default gateway
set, because it is generally recommended to restrict the connections that can be
made through that interface.
2.4.10 Enabling “No Delay Ack” to avoid latency with other systems
If slow performance is observed and a delayed ACK response from an
application replying back to the DataPower Appliance, then a latency issue may
be the cause. For example, this has been observed using applications such as
WebSphere MQ or Tivoli® Access Manager running on AIX®.
While this has been mainly observed on AIX, this could occur on any operating
system that employs a delayed acknowledgment setting.
However, this AIX default setting can slow down performance communicating
between DataPower and some applications such as WebSphere MQ or Tivoli
Access Manager.
Review packet traces from DataPower to see if there is a delay between the
packet sent to AIX and the ACK response coming back from AIX.
For example, in Wireshark/Ethereal, look for the “Time delta from previous
packet” entry for the ACK packet to determine the amount of time elapsed waiting
for the ACK.
To resolve this problem, disable the default ACK delay on AIX by changing the
setting to:
tcp_nodelayack=1
Consult with the AIX system administrator for further considerations about the
impact this may have on the system and for further details of how to do this.
Chapter 2. Networking 51
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
Also, verify that the XML Manager XML Parser XML Bytes Scanned
value used by the service is large enough to handle the desired large file size.
2.5 Examples
This section provides examples of various configuration and troubleshooting
techniques.
XSL will reference the above Meta Data document as shown in Example 2-5.
<dp:xset-target host="$endPoints/BookServiceHost1/ip/text()"
port="$endPoints/BookServiceHost1/port/text()" ssl="false()"/>
Chapter 2. Networking 53
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
In order to shorten the time that the DNS cache exists from the DataPower side,
the DNS servers should be configured with the desired time-to-live. It is
recommended that these settings are consistent across all of the DNS servers
that are configured for usage with DataPower.
Workaround: If this is affecting Production Traffic, enter a static host for the
IP/hostname mapping in the DNS configuration section of DataPower. This will
serve as a temporary workaround so that there is not an outage.
When the interface that handles the DNS traffic has been determined, the
following commands will get DNS information and a packet capture of the DNS
traffic:
co
show dns
show dns-cache
show ip hosts
clear dns-cache
show dns-cache
show ip hosts
int eth<interface number>
packet-capture temporary:///DNStrace.pcap -1 5000
exit
show clock
ping <hostname of failing DNS entry>
<Wait for the console to return before continuing>
show dns-cache
show ip hosts
show clock
ping <IP Address of failing DNS entry>
<Wait for the console to return before continuing>
show dns-cache
show ip hosts
show clock
int eth<interface number>
no packet-capture temporary:///DNStrace.pcap
exit
2.5.6 Sample test to see if Rapid Spanning Tree has been deployed
properly for DataPower Standby Control
If Rapid Spanning Tree is not deployed correctly on the network, then the
Standby Control Appliances may not be able to communicate properly.
If the convergence time is more than 6 seconds, the network has not successfully
deployed rapid spanning tree and the network administrator should be contacted.
Chapter 2. Networking 55
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
#exit
#write memory
#y
The next several steps describe how to measure the spanning tree convergence
time.
4. Start a continuous ping to one of the DataPower interfaces from another
remote host on the network and verify that they are successful.
– Using UNIX®:
ping <DataPower IP>
– Using the Windows® command prompt:
ping -t <DataPower IP>
5. Change the MAC address on the Appliance interface to any MAC address
currently not in use on the network. This should cause the continuous pings
from the remote host to start failing.
– Using the WebGUI:
i. Navigate to Network Interface Ethernet Interface
eth<number>.
ii. Update the MAC address Field and click Apply.
– Using the CLI:
#co
#int eth<number>
#mac-address <mac-address>
#exit
6. From the Appliance, ping a remote address.
– Using the WebGUI:
Navigate to Control Panel Troubleshooting Ping Remote.
– Using the CLI:
#ping <ip-address>
7. Immediately time how long it takes for the continuous pings to become
successful again from the remote host.
Note: If the network has correctly deployed rapid spanning tree, the ping
will resume successfully within 6 seconds.
Return the MAC address to the original MAC address recorded from step 3.
Add the Standby Control configuration back after Rapid Spanning Tree has
been deployed properly.
Chapter 2. Networking 57
7901ch02.fm Draft Document for Review April 13, 2011 6:45 am
If connectivity is lost after removing a static route, then check to see if the serial
console is working. If so, then a particular route or default route may need to be
defined. Use the serial console to set a default route/gateway to recover the
network connectivity.
Note: Be sure to set the default route/gateway before deleting static routes on
the connected ethernet interface.
Use the following stylesheet in a Transform Action to insert the transaction ID into
the HTTP headers.
<xsl:template match="/">
<xsl:variable name="tid"
select="dp:variable('var://service/transaction-id')"/>
<xsl:message dp:priority="info">
<xsl:text>Transaction ID: </xsl:text>
<xsl:value-of select="$tid"/>
</xsl:message>
</xsl:template>
</xsl:stylesheet>
Now the transaction ID can be viewed in the packet capture and search the logs
for corresponding events quickly and easily.
Chapter 3. Domains
From a cost perspective, one of the benefits of using DataPower appliances is
the ability to use the same physical device to support many different projects and
implementations. To support this level of versatility, DataPower appliances
provide management functions for the separation of a single physical appliance
into one or more logical instances called domains.
This chapter discusses the various benefits, uses, configuration, and best
practices that are associated with DataPower domains.
How a DataPower appliance is divided depends largely on its role within the
enterprise. For example, a development appliance might contain the following
domains:
Chapter 3. Domains 61
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
Chapter 3. Domains 63
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
export: Contains the exported configurations that are created with the Export
Configuration utility. Each application domain contains one export:
directory. This directory is not shared across domains.
cert: Contains keys and certificates for application development. Keys and
certificates in this folder are specific to an application domain and are
not accessible from any application domain. You must be in the
specific application domain to create or upload keys and certificates
to this folder.
chkpoints: Contains the configuration checkpoint files for the appliance. Each
application domain contains one chkpoints: directory. This directory
is not shared across domains.
local: Contains miscellaneous files that are used by the services within the
domain, such as XSL, XSD, and WSDL files. Each application
domain contains one local: directory. This directory can be made
visible to other domains.
logstore: Contains log files that are stored for future reference. Typically, the
logging targets use the logtemp: directory for active logs. You can
move log files to the logstore: directory. Each application domain
contains one logstore: directory. This directory is not shared across
domains.
logtemp: This directory is the default location of log files. Each application
domain contains one logtemp: directory. This directory is not shared
across domains.
Table 3-2 Domain directories that are shared across all domains
Directory Usage
sharedcert: Contains keys and certificates for application development. Keys and
certificates in this folder are accessible from any application domain.
However, you must be in the default domain to create or upload keys
and certificates to this folder.
store: This directory contains example style sheets, default style sheets,
and schemas that are used by the appliance. Do not modify the files
in this directory. Each appliance contains only one store: directory.
By default, this directory is visible to all domains. The store:
directory has the following subdirectories:
meta: Files used by the appliance itself
msgcat: Message catalogs
policies: Predefined WS-Policy definition files
profiles: Style sheets used by DataPower services
schemas: Schemas used by DataPower services
dp: Encrypted, internal-use files
pubcerts: Used internally by the appliance
Table 3-3 Directories accessible from the CLI only in the default domain
Directory Usage
audit: Contains the audit logs. Each appliance contains only one audit:
directory. This directory is available from the command line in the
default domain only and is not visible from the WebGUI.
dpcert: This encrypted directory contains files that the appliance itself uses.
This directory is available from the command line in the default
domain only and is not visible from the WebGUI.
image: Contains the firmware images for the appliance. This directory is
where firmware images are stored during an upload or fetch
operation. Each appliance contains only one image: directory. This
directory is available in the default domain only.
tasktemplates: Contains the XSL files that define the display of specialized WebGUI
screens. Each appliance contains only one tasktemplates:
directory. This directory is visible to the default domain only.
Chapter 3. Domains 65
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
The configuration script for the default domain is named autoconfig.cfg. The
configuration script in each application domain is named the same as the domain
with a .cfg extension. For example, the configuration file for a domain named
wsgateway would be wsgateway.cfg and would be found in that domain’s config:
directory.
As you might expect, each domain can control the level (or severity) of log
messages that are generated within the domain. Log levels range from
emergency to debug, with the latter generating the most log messages. Setting
the log level in one domain has no effect on logging in other domains. You can
determine the log level for a specific domain by clicking the Troubleshooting
Panel icon from within the main Control Panel.
Chapter 3. Domains 67
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
These newly created objects are alive and functional and can perform work
tasks, but they are not yet part of the domain’s saved configuration. In other
words, these newly defined objects are not yet written into the domain’s
configuration file. After you save the configuration (by either clicking the Save
Config link or by executing the write memory CLI command), the newly created
objects are added to the domain’s configuration file. (See Figure 3-1 for the
location of the Save Config link.) If the domain is restarted or the appliance is
rebooted before the configuration is saved, the newly created objects will be lost.
Configuration note: Configuration changes are not saved into the domain’s
configuration file until you click the Save Config link.
This same rule holds true when modifying pre-existing objects. For example, if a
developer modifies a request processing rule to include a new XSL transform
action, the functionality becomes immediately available to any messages that
pass through the service. However, the domain’s configuration file does not
reflect this new action until the developer clicks the Save Config link to persist
the modifications.
Figure 3-1 The Save Config link is located towards the top of the WebGUI
Local domains
Domains that are purposed for development are always defined as local. As
developers modify the objects within the domain, they save the active
configuration to the local configuration file. If the domain or appliance is
restarted, the saved configuration is used to reconstitute the domain.
Imported domains
Imported domains fetch their configuration from a remote location. This type of
domain is read-only. After a domain is initialized, any changes that occur to the
running configuration cannot be saved, which disqualifies imported domains for
development use. However, imported domains are ideally suited for test and
production environments.
Chapter 3. Domains 69
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
Domain visibility is useful for viewing or copying file resources that are located in
another domain’s local: directory. For example, a team can create a single
domain to hold XSL templates that are modified frequently for various
applications. This domain can then be visible from developer domains, allowing
developers to copy the files into their local: directories.
Do not confuse domain visibility with domain sharing. Files or artifacts that are
located within a visible domain’s local: directory cannot be directly referenced
by configuration objects. For example, an XSL template located in domain1’s
local: directory cannot be used in a Transform action within domain2. The XSL
template first must be copied from domain1’s local: directory into domain2’s
local: directory before it can be referenced by a transform action.
Copying the configuration file does not automatically include any artifacts that
exist in the source domain’s local: directory; therefore, it might be necessary to
copy the contents of the source domain’s local: directory to the new domain as
well. It might also be necessary to upload any dependent private key material.
Chapter 3. Domains 71
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
Example 3-1 shows the CLI commands to copy a domain to a new domain.
Note that no files from the local: directory are copied to the new domain. If you
need to copy files from the local: directory, use the CLI copy command or the
WebGUI.
Restarting
It is possible to restart an application domain, including the default domain,
without restarting the entire appliance. The application domain is reconstituted
using the currently saved configuration for the domain. In the event that the saved
configuration differs from the running configuration, a notice displays that
prompts the user to save the configuration before restarting.
There is no effect on the contents of the domain’s flash file system. Restarting a
domain is an immediate action and does not wait for in-flight transactions to
complete. If you need to wait for in-flight transactions to complete, quiesce the
domain before restarting (see 3.4.4, “Quiescing” on page 73).
Resetting
Resetting a domain has the effect of deleting all configuration objects from the
running configuration but not from the saved configuration. In-flight transactions
are abandoned. If in-flight transactions should complete first, quiesce the domain
prior to resetting it (see 3.4.4, “Quiescing” on page 73).
Clicking the Save Config link after resetting a domain causes the new empty
running configuration to be saved to the domain’s configuration file and
permanently removes all service objects.
3.4.4 Quiescing
DataPower firmware version 3.8.1 introduces the quiesce function that allows an
administrator to bring down a domain (or any service object) in a controlled
manner. Quiescing causes the domain objects to stop accepting new
transactions while continuing to finish processing any existing activities. In
production environments, quiescing helps to guarantee that any in-flight
transactions will complete before the domain is brought down.
Chapter 3. Domains 73
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
Ethernet 0 9.33.83.100
Ethernet 1 9.33.83.101
The services within the application domains can be forced to have their inbound
and outbound traffic isolated to a specific interface. If AppDomA has an XML
firewall (with a static backend) and a Multiprotocol Gateway (MPGW) and if all
traffic should go over Ethernet 0, you would associate the inbound traffic on the
service by specifying the IP address 9.33.83.100 on both the XML firewall and
the HTTP front-side handler for the MPGW. Static routes are then defined on
Ethernet 0 for the destination addresses of the XML firewall and the MPGW.
In this simple example, the services that are associated to AppDomA have all of
their inbound traffic restricted to Ethernet 0, and after the XML firewall or MPGW
opens an outbound connection, it goes out Ethernet 0 following the static route.
Chapter 3. Domains 75
7901ch03.fm Draft Document for Review April 13, 2011 6:45 am
This chapter discusses DataPower monitoring and presents strategies and best
practices for using it. It will cover:
Enabling monitoring of DataPower from SNMP tools
Producing SNMP alerts from within DataPower
Configuring log targets to produce alerts based on system events
Event subscriptions
Monitoring best practices
command line interface (CLI) - accessed via SSH or the appliance’s serial
interface; provides network administrators with a familiar command line
environment for initial device setup and configuration (see Figure 4-2).
Unlike SNMP which focuses exclusively on device monitoring, the WebGUI, CLI,
and XMI can provide access to every aspect of a DataPower appliance, including
configuration, administration, and monitoring.
When the SNMP manager wants to know the value of an object or characteristic,
such as DataPower’s current system load, it will assemble a GET packet that
includes the dpStatusSystemUsageLoad OID. If the agent understands the OID,
it will create a response packet and return the value, otherwise a special error
response is returned. Similarly, when an agent wants to send a TRAP to the
manager, it will create a TRAP packet and include the OID and value information
to advise of the event.
associated with the default domain. Other status providers are application
domain specific, such as those that measure service transaction rates. These
status providers may be further segmented by XML-Manager or DataPower
service.
A message digest is created for each packet using a combination of the Keyed
Hashing for Message Authentication (HMAC) algorithm, and either the Message
Digest 5 (MD5) or the Secure Hash Algorithm 1 (SHA-1). When either the
manager or the agent receives a message, they calculate a message digest and
compare it with the received one. If the digest does not match, the packet is not
authenticated and it is dropped. If privacy is configured, packets are encrypted
using the Cipher Block Chaining mode to the Data Encryption Standard
(CBC-DES) algorithm.
Local IP Address - the IP address that In the manager, this address is referred to
DataPower will expect incoming SNMP as Remote IP Address or Agent IP
connections on. Typically this is set to a Address.
host alias that maps to the management
interface IP (mgt0). This restricts SNMP
polling requests to this IP only, and
prevents any SNMP requests from being
received over client traffic interfaces (eth0,
eth1, or eth2).
Local Port - used for inbound SNMP This value must match the agent’s port
polling requests. when setting up the manager.
Best Practice: A Host Alias should be defined (in the default domain) and
used instead of an actual IP address.
EngineID: Leave this field This unique value is used at various times through the
“0” and let DataPower SNMPv3 authentication and encryption process.
provide it.
The manager generally fetches this during initial contact
with the agent.
Figure 4-5 SNMPv3 Parameter relationships for DataPower and SNMP Manager
The Enterprise MIBs tab, shown in Figure 4-6, lists three DataPower MIBs that
can be downloaded and imported into any SNMP manager. There’s a MIB for
each of configuration, status, and notifications.
Trap subscriptions
The Trap Event Subscription tab enables the selection of which DataPower event
codes will be sent to the management console as alerts. Figure 4-7 shows the
Trap Event Subscription tab. Additional event codes can be added as needed by
clicking the Select Code button. If a specific code is not shown in the list, it can
be added manually.
SNMP communities
SNMP communities are used by SNMPv1 and SNMPv2c to establish trust
between managers and agents. Community names are essentially used as
credentials to access SNMP data on the appliance. There are three types of
communities:
Read-only, allows only reading of data values. A commonly used name for
read-only access is public.
Read-write, allows reading and modifying of data values.
Trap, allows receipt of asynchronous notifications (traps) from the agent.
Best practice: Since community strings are essentially passwords that allow
access to the SNMP agent, community strings should adhere to the same
creation rules (mixed case, must contain a number, etc.) as passwords.
Best practice: Unless it is necessary for the SNMP manager to set values
from MIB-II and other IETF MIBs, it is recommended that all communities
defined on DataPower be read-only. There are no read-write values defined
within the DataPower MIBs.
Community strings are sent from monitoring software to the agent in clear text.
For this reason, it is important to assure that firewalls are properly configured to
protect the SNMP infrastructure. SNMPv3 addresses this problem by
establishing secure authentication and communication between SNMP devices.
SNMPv3 contexts
Setting up SNMPv3 context allows SNMP managers to gain access to
non-default application domains. See Figure 4-11.
Follow these steps to create a log target that subscribes to critical MQ events:
1. On the main tab, specify a meaningful name for the log target (See
Figure 4-12 on page 94).
2. In Target Type, select SNMP.
3. Select the Event Subscriptions tab, then click Add to add a new event
subscription.
4. For the Event Category, select: mq
5. For the Minimum Event Priority field, select: critical
6. Click Apply to save the subscription (See Figure 4-13).
7. Click Apply to save the log target.
Whenever a critical MQ message is logged within the domain, the log message
will be used as the basis for an SNMP trap. Any managers subscribing for traps
will receive the notification.
The XML Management Interface exposes several endpoints which are accessible
via URI. One such endpoint is the SOAP Configuration Management (SOMA)
interface, a service that provides a set of operations for both monitoring and
configuring DataPower appliances. The Web Services Description Language
(WSDLs) and schemas for SOMA can be found in DataPower’s store: directory.
Once selected, the XMI can be enabled and the network-related settings can be
customized as necessary (see Figure 4-14). Table 4-4 on page 96 discusses the
various configuration options available.
Best practice: Use a host alias when specifying the IP address for the XML
Management Interface, especially in production environments. Leaving the IP
address as 0.0.0.0 allows requests to be received on any IP address defined
on the appliance. Generally speaking, the management interface is used for
XMI traffic (mgt0 or eth4).
Local IP Address Specifies the IP address that exposes the XMI. It’s best practice
to specify a previously defined host alias which maps to the
management interface. Specifying 0.0.0.0 allows access to the
XMI from any active Ethernet interface and is especially not
recommended in production environments.
Option Value
Access Control List Allows access to the XMI from only specified IP addresses.
Usage depends on organizational security requirements.
For a complete list of classes attributes that can be used in the SOMA get-status
request, see the store:/xml-mgmt.xsd schema and search for the text
“StatusEnum”.
Note: The XML examples showing the SOMA responses have been slightly
simplified for the purpose of brevity. Specifically, the SOAP Body and
Envelope elements have been removed, large repeating elements have been
removed (and noted), and some namespaces have been shortened. The XML
examples are provided for reference to see exactly what data is returned on
the request.
Requests are not shown but a fully functional SOM request can be seen in
Example 4-2 on page 97. Replacing the CPUUsage class with the class
specified in this section will yield the desired status values.
System usage
System Usage is a measurement of the device’s ability to accept additional work.
It is a formulaic calculation based on various components of system load,
including CPU, memory, and filesystem utilization. System Usage is typically
considered the best single indicator of overall system capacity. While it may
sometimes spike to 100%, typical values are less than 75%. The secondary work
list value is a calculation of internally queued tasks, and is of lesser interest in
typical monitoring situations.
Table 4-5 shows the various ways for obtaining system usage metrics.
Figure 4-15 shows system usage as displayed in the WebGUI, and Example 4-4
and Example 4-5 show the SOAP response from the XMI request for
SystemUsageTable and SystemUsage.
</SystemUsageTable>
</dp:status>
</dp:response>
CPU usage
CPU Usage statistics are provided over five time intervals. CPU utilization is not
as reliable as System Usage in determining device capacity. DataPower is
self-optimizing, and spikes in CPU not associated with traffic levels may occur as
the device performs background activities. Spikes as high as 100% are not
unusual and should not raise concern unless it is sustained over numerous
consecutive polls.
Table 4-6 shows the various ways for obtaining CPU usage metrics. Figure 4-16
shows CPU usage as displayed in the WebGUI, and Example 4-6 shows the
SOAP response from the XMI request for CPUUsage.
Memory usage
Memory Usage statistics are provided for various classifications of the
appliance’s flash memory. Statistics including a percentage of total memory
utilized; bytes of total, used and free memory; and of lesser interest in typical
monitoring, reque3st, XG4, and held memory. The percentage of used memory
depends on the application, the size of request and response messages, and the
volume and latency of requests. Typical utilization runs are less than 80%, and
statistics beyond this threshold are of concern. You can use the device’s Throttle
Settings to temporarily slow down request processing or to perform a warm
restart, which recaptures memory in this situation.
Figure 4-17 shows system error codes that are associated with these sensors
and can be used to trigger alerts from the SNMP Trap Event Subscription
configuration.
Table 4-7 shows the various ways for obtaining memory usage metrics.
Figure 4-18 shows memory usage as displayed in the WebGUI, and Example 4-7
shows the SOAP response from the XMI request for MemoryStatus.
Figure 4-19 shows system error codes that are associated with these sensors
and can be used to trigger alerts from the SNMP Trap Event Subscription
configuration.
Table 4-8 shows the various ways for obtaining filesystem usage metrics.
Figure 4-20 shows filesystem status as displayed in the WebGUI, and
Example 4-8 shows the SOAP response from the XMI request for
FilesystemStatus.
System up time
System up time indicates the elapsed time since the device was last restarted,
including controlled firmware reloads as well as any unexpected device restarts.
DataPower appliances restart themselves automatically in conjunction with
throttle configurations such as memory or file system constraints.
Even though SNMP notifications are sent in the event of a restart, it is possible
that message delivery fails due to the conditions that may have caused the
restart in the first place. For this reason, it is prudent to rely on both SNMP traps
as well as SNMP polling to assure that any notification delivery failure will not
obscure the fact that the machine was restarted. Uptime is an ideal metric for
determining the last time an appliance restarted.
Table 4-9 shows the various ways for obtaining system time metrics (including
uptime). Figure 4-21 shows date and time status as displayed in the WebGUI,
and Example 4-9 shows the SOAP response from the XMI request for
DateTimeStatus.
Temperature sensors
Sensors for obtaining CPU, Memory, and System temperatures can be queried to
ascertain whether the components are operating within acceptable temperature
ranges. Each component has a warning and danger temperature associated with
it and a status value of OK or FAIL. High temperatures may be the result of
ambient temperature or fan failures.
Table 4-10 shows the various ways for obtaining temperature sensor metrics.
Figure 4-22 shows temperature sensor status as displayed in the WebGUI, and
Example 4-10 shows the SOAP response from the XMI request for
TemperatureSensors.
Fan sensors
Proper fan operation assures that DataPower appliances can operate safely
within normal ambient conditions. The number of fans within the case may vary
depending on installed options. Fan malfunctions potentially can lead to device
overheating and malfunction, therefore it is important to proactively monitor their
condition.
Figure 4-23 shows system error codes that are associated with these sensors
and can be used to trigger alerts from the SNMP Trap Event Subscription
configuration.
Table 4-11 shows the various ways for obtaining temperature sensor metrics.
Figure 4-24 shows temperature sensor status as displayed in the WebGUI, and
Example 4-11 shows the SOAP response from the XMI request for
EnvironmentalFanSensors.
Other sensors
Sensors that are more specific to DataPower appliances are grouped into the
Other Sensors category, including intrusion detection, battery, hard disk, and
power supply indicators.
Figure 4-25 shows system error codes that are associated with these sensors
and can be used to trigger alerts from the SNMP Trap Event Subscription
configuration.
Table 4-12 shows the various ways for obtaining other sensor metrics.
Figure 4-26 shows other sensor status as displayed in the WebGUI, and
Example 4-12 shows the SOAP response from the XMI request for
OtherSensors.
</dp:status>
</dp:response>
Table 4-13 shows the various ways for obtaining ethernet interface metrics.
Figure 4-27 shows status as displayed in the WebGUI, and Example 4-13 shows
the SOAP response from the XMI request for EthernetInterfaceStatus.
Receive/Transmit throughput
Receive and transmit throughput information can help understand the amount of
data being processed by the device. These statistics are provided for five time
intervals ranging from 10 seconds up to the most recent 24 hour period and help
capture and understand network load. Metrics include traffic on the mgt0
(management) interface, so WebGUI, CLI, and other management traffic is
included in the totals.
Table 4-14 shows the various ways for obtaining receive and transmit throughput
metrics. Figure 4-28 and Figure 4-29 shows status as displayed in the WebGUI,
and Example 4-14 and Example 4-15 shows the SOAP response from the XMI
request for ReceiveKbpsThroughput and TransmitKbpsThroughput.
Note: HTTP Connection status statistics do not include connection data for
services configured as loopbacks.
When using SNMP to obtain HTTP connection status, the target domain is
specified when setting up communities (for SNMPv1 and SNMPv2c) or when
setting up contexts (for SNMPv3).
Table 4-15 shows the various ways for obtaining HTTP connection statistics.
Figure 4-30 shows status as displayed in the WebGUI, and Example 4-16 shows
the SOAP response from the XMI request for HTTPConnections.
<offerTenMin>0</offerTenMin>
<offerOneHr>0</offerOneHr>
<offerOneDay>0</offerOneDay>
<destroyTenSec>0</destroyTenSec>
<destroyOneMin>0</destroyOneMin>
<destroyTenMin>0</destroyTenMin>
<destroyOneHr>0</destroyOneHr>
<destroyOneDay>66</destroyOneDay>
</HTTPConnections>
<HTTPConnections xmlns:env="http:...[omitted]...soap-envelope">
... repeated for additional XML Managers ...
</HTTPConnections>
</dp:status>
</dp:response>
Table 4-16 shows the various ways for obtaining receive and transmit throughput
metrics. Figure 4-31 and Figure 4-32 shows status as displayed in the WebGUI,
and Example 4-17 and Example 4-18 shows the SOAP response from the XMI
request for HTTPTransactions and HTTPMeanTransactionTime.
Being able to ascertain the normal traffic patterns of applications over time helps
to predict growth and capacity requirements. The SNMP MIB values shown in
Figure 4-35 can be queried to help capture and monitor the amount of network
traffic that the device is processing.
Figure 4-36 on page 122 shows an example of the crypto certificate monitor
object. You can customize and tune crypto certificate object settings such as the
Polling Interval, Reminder Time, and Log level. These settings need to be in
agreement with your company’s certificate replacement policy.
Every time a certificate expiry date is within the Reminder Time, a log message
with the specified log level is generated in the appliance system’s logs. You can
also set the expired certificate object to be automatically disabled.
Important: Keep in mind that any other crypto objects that reference the
disabled certificate object will also be disabled.
For better results and visibility regarding certificates expiry, always enable the
crypto certificate monitor functionality. The device administrator needs to make
sure this step is included on every initial setup process.
During a log target setup, you must set up an event category subscription. A log
category is used to relate log events and messages under a same subject. Thus,
a category determines the subjects in which a log target is interested. A log
target receives only messages that are related to its subscribed categories.
DataPower appliances come with some log categories set and enabled by
default. A useful category for certificate monitoring is the cert-monitor category.
You can use this category when setting monitoring for certificates expiry.
An example would be to have the device administrator group emailed every time
a certificate expired log entry is found. Alternatively, the production support team
can be paged, or perhaps both situations can occur. The monitoring response
can vary depending on your company support process.
It is essential that anyone who works with monitoring traps have a deep
knowledge of the monitoring suite that is used. Alerts and alarms are generally
not enabled by default. They need to be enabled and set based on your company
criterion. For best results when monitoring certificates, set alarms and traps.
Remember that your partners have their own policy for dealing with certificates.
Some partners can take more time to deploy a new certificate than others. Also,
certificates need to be signed by a certificate authority (CA). Each CA has their
own service level agreement (SLA), which can also cause a delay.
This chapter introduces the various Tivoli components and how they work
together with DataPower appliances.
Mo nitor ing
Re mote a gents
Tivoli Enterprise
XXX X
XXX XX
XXX
XXX XX
Monitoring Server
Tivoli Enterprise
Portal
b rowser clie nt
DB2
or Monitoring
XXX X
XXX XX
XXX
XXX XX
MSSQL agents
Tivol i Enterprise
Hub Tivoli Ente rprise
Por tal Server
Monitoring Server
Ti voli Enterprise
Portal
desktop client
Tivoli Data
Monitoring Agents
Tivoli Enterprise Monitoring Agents are responsible for collecting application and
resource metrics from various enterprise systems. In most cases, the agents run
within the system that they monitor, however agents that monitor DataPower
appliances are located on separate servers and are capable of monitoring
multiple DataPower appliances simultaneously.
Tivoli Monitoring -based products supply a variety of different agent types which
are compatible with different types of systems. For example, IBM Tivoli
Composite Application Manager for SOA (ITCAM for SOA) includes a number of
monitoring agents, several of which are specific to DataPower appliances.
The metrics collected by each monitoring agent are packaged and transmitted to
a Tivoli Enterprise Monitoring Server (TEMS) for further analysis.
The hub monitoring server correlates the monitoring data that is collected by
monitoring agents and any remote monitoring servers and passes that data to
the Tivoli Enterprise Portal Server for presentation by portal clients. It may also
be configured to forward data to the data warehouse for subsequent inspection
and analytics.
Data warehouse
The Tivoli Data Warehouse is an optional component for storing historical data
that is collected from the various monitoring agents. It includes a relational
database that allows historical and trending analysis of all collected metrics. This
analysis is useful for baselining and viewing peak load periods for an hour, day,
week, or other specified time period.
Event synchronization
The event synchronization components are optional. These components are
configured to send situation event updates that were forwarded to a Tivoli
Detect that a Pinpoint the problem Drill down into Fix the faulty
threshold has been to a specific part of the details and component,
breached and that a the environment and get to the root validate the fix
problem occurred, or hand-off to the cause of the and roll back into
is about to happen appropriate specialist problem production
Integration begins at the data layer, where a common data model enables a
consistent view of information across all components and agents. This
information is then consolidated in Tivoli Enterprise Portal which provides single
sign-on to the monitoring data and management tools needed for server
management, application management, transaction management, and advanced
management capabilities.
The remainder of this chapter will focus on the ITCAM for SOA product and its
relationship to DataPower appliances.
The ITCAM for SOA Web Services Navigator provides the following capabilities:
Topology View: A graphical representation of the interactions between all
monitored web services
Statistics View: Tables of the metric data that is collected by the agents at
each interception point
Sequence Diagram: The exact sequence of messages over time (UML-like
sequence diagrams and call flows)
These agents complement each other and provide excellent control and visibility
of DataPower devices.
ITCAM for SOA ships with and plugs in to the Tivoli Monitoring framework. Tivoli
Monitoring provides the base enterprise-class monitoring functionality, including
alerting, performance thresholds, historical trending analysis, reporting
capability, high availability, and policies to perform actions, to schedule work, and
to automate manual tasks (see 5.1, “IBM Tivoli Monitoring environment
architecture”).
The data collector agent forwards the extracted metrics to a Tivoli Enterprise
Monitoring Server where it can be consolidated with metrics from other ITCAM
agents such as .Net, WebSphere, Weblogic, etc. This aggregate of metrics
allows for a greater visibility of not only DataPower application traffic, but also the
up and down stream services and components that affect overall application
throughput.
Figure 5-5 Web service topology diagram with alerts and metrics
The web service topology diagram workspace allows for the creation of service
groups. A service group encapsulates a set of operations that collectively provide
some business function such as createPolicy or lookupCustomer (see Figure 5-6
on page 133). ITCAM for SOA can provide management of the SOA environment
monitoring from the edge, through DataPower devices, and following the service
to service hops. ITCAM for SOA ships with the agents that are required to track
this flow from both distributed applications through the mainframe, such as CICS
on zOS.
ITCAM for SOA can also determine unavailability for services and service groups
in the following terms:
Unavailability by faults: Situations triggered when faults are detected
Absence of expected traffic: Situations triggered by monitoring traffic volumes
Requests without responses: Situations triggered by missing or invalid
responses
Request/response/fault counts: Situations triggered by the ratio of requests to
responses or faults
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/topic/com.ibm.itcamsoa.do
c/kd4ugmst204.htm#app_attributes.
Figure 5-7 ITCAM for SOA view of DataPower services for various time intervals
Similar to the ITCAM for SOA DataPower data collector, this agent can also
monitor transaction-level metrics using the DataPower latency logs. This method
Although the ITCAM Agent for WebSphere DataPower Appliance has the ability
to monitor transaction-level metrics, they are not automatically correlated or
aggregated, thus it can be difficult to find the start of a transaction.
Figure 5-8 shows an example view of system log content extracted by the ITCAM
Agent for WebSphere DataPower Appliance. The view in Figure 5-9 shows
uncorrelated latency logs.
Figure 5-9 DataPower latency logs show non-correlated transaction level metrics
Figure 5-10, Figure 5-11, Figure 5-12, and Figure 5-13 show samples of the
numerous workspaces that ship with this solution.
Figure 5-11 DataPower system uptime, HTTP mean transaction, system load, CPU, and memory usage
Figure 5-12 DataPower system logs: View latency details of a specific transaction
The ITCAM for SOA DataPower data collector, which provides a complete
application-level monitoring solution. It focuses on monitoring application
traffic that is routed through MPGW and WS-Proxy service objects.
Table 5-1 shows the differences between the two DataPower agents.
Primary focus: Device health metrics Primary focus: Application traffic metrics
Quick deployment, especially for MPGW XSL stylesheets are required for MPGW
objects: monitoring:
No need to implement XSL Takes longer to deploy and manage
stylesheets for every MPGW intrusive to code flow
Not required to code XSL stylesheets
for each object flow Automatic correlation and service
No need to map non-SOAP XML discovery can be achieved
messages
No need for maintenance of XSL Supports MPGW and WS-Proxy objects
stylesheets
Allows for graphical topology with alerts
Supports XML Firewall objects as well as and metrics in Tivoli Enterprise Portal
MPGW and WS-Proxy objects
Service group features
Detailed information about the flow itself
(latency logs): Data Aggregation (averages, standard
Includes metrics on front and deviations, min/max, missing
backside as well as latency of object percentages, faults, and so forth)
flow itself (the application)
Data on Individual Transactions - Message content available
near-real time
Requestor ID tracking support
Latency logs contains individual
transaction details and data; potential Web Services Navigator tool
performance implication
WSRR, Tivoli Application Dependency
Discovery Manager (TADDM), and Tivoli
Businses Service Manager (TBSM)
integration using Discovery Library
Adapters (DLAs)
User Interfaces
Web Services
Custom Scripts TEPS Client
Navigator
DataPow er Appliance
Transaction metadata
Transaction Log
and optional payload
Events, Faults, Audit WS transaction metrics, fault
Logging System Log
Messages info, and optional payload data
for transaction breakdown Tivoli Enterprise
Latency Messages Latency Log
Portal Server
(TEPS)
Current D4 Agent Agent Logs
Focus on DP Services
Real-time
Alerts and Monitoring
Web Services Transaction metadata
Data ITCAMfSOA
Mgt (WSM) and optional payload contents
(TCP) Collector Agent Single message
Buffer
and summarized
data
New BN Agent Focus Tivoli Enterprise
Management Server
on hardware usage (TEMS)
with some visibility Near real-time
and summarized
into services Data data
Collector Historical Data
Polled MIB data: CPU, Memory, Interfaces Data ITCAMfWDP
(UDP) Collector Agent
SNMP Summarized
Traps Data data
(UDP) Collector
Tivoli Data Warehouse
Agent Host (TDW)
Summarized
data
Tivoli Monitoring
Infrastructure
the DataPower device for the ITCAM for SOA DataPower data collector agent
(see Figure 5-15).
TEP Client
ITCAM/SOA Agent
and
Agent DataPower Data
Collector
TEMS
Data
Collector
Traffic
Generators
DataPower Production
Integration Appliance Servers
WebSphere
SOAP/XML/HTTPs
.NET
BEA
Operation 1
Load Balancing
Redundant DataPower; Security,
XML Transformations and Routing Custom Operation 2
Tivoli Portal
ITCAM for
SOA DP ITCAM for SOA v7.1.x
Agent (application support)
+ Navigator
ITM v6.2.2.x
• TEPS
DB • TEMS
The ITCAM for SOA DataPower data collector agent can aggregate data for
multiple DataPower appliances and/or multiple DataPower domains, allowing for
varied architecture patterns such as that shown in Figure 5-16.
The Web Service Proxy is ideally suited for application traffic monitoring since its
traffic is always predictable and will be either a SOAP request, response, or fault.
For this reason, the ITCAM for SOA DataPower data collector can easily extract
and interpret detailed service-related metrics including fault codes and
messages. Configuration of the WS-Proxy is minimal in this case.
metrics have been published to WSM, ITCAM for SOA monitoring agents can
extract the metrics and report them back to TEMS.
For an in-depth description of integrating ITCAM for SOA with WS Proxy and
Multi-protocol Gateway services, please refer to Composite Application Manager
for SOA, Version 7.1.1, Installation Guide - “Configuring processing rules for
DataPower Multi-Protocol Gateways” or visit:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.it
camsoa.doc/kd4inmst148.htm
Note: for the deployments described in this section, some of the Tivoli
Monitoring components have been omitted for simplicity.
Lab Architecture
Op A
DataPower XI50 Op B
ITCAM for Op C
SOA DataPower
Agent (D4) Op D
Domain 1 Domain N
...
. . . . . .
ITCAM for
SOA DP
Agent (D4)
ITCAM
• Remote TEMS
(RTEMS)
collectors transmit metrics to a single remote monitoring server which relays the
data to the hub monitoring server. The use of remote monitoring servers
facilitates future growth; additional remote monitoring servers can be deployed,
each feeding metrics into the hub monitoring server.
Domain 1 Domain N
. . .
. . . . . .
ITCAM for ITCAM for
SOA DP SOA DP
Agent (D4) Agent (D4)
ITCAM
• Remote TEMS
(RTEMS)
Figure 5-19 Large multi-location multi-agent deployment with remote monitoring servers
Domain 1 Domain N
. . .
. . . . . .
ITCAM for ITCAM for
SOA DP SOA DP
Agent (D4) Agent (D4)
Domain 1 Domain N
Additional ITCAM / Ome gam on Components
Other O ther
ITM TEMA ITM TEMA
Agents Agen ts
...
...
Remote Remote
TEMS TEMS
ITCAM (RTEMS) (RTEMS)
• Remote TEMS ...
ITCAM Agent (RTEMS)
for DP (BN)
a lso
Log Target
SLM policies can contain simple rules as well as complex rules involving
message inspection and XPath evaluation. For example, limit the number of
times a service is called by a specific user for a specified SOAP operation.
SLM policies can reference latency values, causing notifications to occur if
backend processes exceed certain thresholds.
Service level monitors can be applied across multiple DataPower devices,
allowing installations to enforce SLM policies based on aggregated counts
across peer devices.
Basic graphing through the WebGUI. A simple graph can be displayed
showing throttled, shaped, and notified transaction counts over a period of
time.
In general, The DataPower SLM feature is excellent for ESB-like capabilities and
individual DataPower appliance troubleshooting, but it was not intended to serve
as an enterprise-wide, operations level monitoring solution. ITCAM for SOA
provides the following capabilities above and beyond what DataPower’s built-in
SLM can provide:
Long-term storage of transaction metrics for subsequent analysis, historical
graphing, reporting, and compliance.
Easy cross-referencing of metrics and correlation to other environmental
components.
Impact analysis and “drill-down” for root cause analysis.
The remaining topics in this section address specific considerations that can help
assure that a deployment functions both reliable and efficiently. These
considerations focus primarily on agent deployment and DataPower
configurations.
Chapter 6. Logging
Organizations of all types and sizes need to keep a record of activity within their
enterprise computing systems, particularly when those systems interact directly
with external customers. Only by keeping such records, or logs, can the
organization find the cause of failures or unexpected results, or, in some cases,
prove that any given transaction actually did occur. A robust logging system can
also be used to continually monitor all enterprise systems, to ensure that each
system is performing as expected and that corporate guidelines are followed.
Similar to using a security camera in a brick-and-mortar store, logging does not
prevent incidents from happening but can help to identify the root cause of an
issue.
This chapter provides information that can help in planning a logging solution.
Topics covered include the following:
Overview of the DataPower logging systems
Log types and destinations available
Methods for event and transaction logging
Privacy considerations
Best practice recommendations
6.1 Overview
The device offers two distinct types of logging:
Message process logging
These logs capture log messages generated as the device processes
messages flowing through the device. The device can generate two kinds of
processing messages: event-driven messages and transactional messages.
Audit logging
Audit logs capture messages generated by changes to the configuration of
the device, or by administrators logging into the device.
The Audit logs and the Message process logs are distinct, and require different
handling procedures.
wide range of log targets that subscribe to any subset of published streams,
enabling administrators to capture only the information desired.
The containers, or objects, that subscribe to published log messages are called
log targets. Administrators can create any number of log targets, each
subscribed to different categories of log messages or of error events. It is
possible to create log targets that are highly focussed and thus provide rapid
access to only the log messages or other events of interest. It is also possible to
create log targets that capture a wide range of messages, providing a general
context for processing events within the device.
If the device offers hard drive storage, the hard drives can be used for log
storage. Even when using the hard drives, log archive files need to be moved off
of the device at regular intervals.
The contents of the Audit log can be obtained by generating an Error Report.
This report contains the audit log entries.
6.2 Benefits
A robust logging system provides enterprises with a number of benefits, such as
the ability to comply with governmental regulations or implement an enterprise
auditing policy.
6.3 Usage
The logging capabilities of the device offer a great deal of flexibility. The
enterprise business requirements regarding logs and records determine the
logging methods used for any given deployment. The DataPower device can
support the following degrees of reliability in logging:
Best Effort Event Logging
Log messages are generated and captured as events occur during normal
message processing. In the event the device needs the processing power and
memory to process transactional messages rather than handling logging, the
device will pre-empt the logging system in favor of transactional processes.
Log messages may be lost as a result. The standard logging system
employing log targets offers this best effort logging.
Reliable Logging
The device will hold up the processing of messages to ensure that the desired
logs are created and delivered as needed to meet the business requirements.
The device offers the Log Action, a processing policy action, to accomplish
this task. The Log Action, when used in this way, does not employ the
standard event-driven logging system but rather sends log messages off the
device immediately. As defined above, this makes logging part of the
transaction processing, and can include a copy of the transaction message in
the generated log. This same objective can be reached using a Results
Action in the processing policy.
In addition to event subscriptions, log targets offer the ability to create filters of
various kinds. Filters restrict the messages captured by the log target. Filters can
be any of the following types:
Event filters
Event filters either include only messages with the designated event code
within them or exclude messages with the designated event code within them,
Object filters
Object filters include only messages published by the selected object class
and name. The name can be a wildcard, including all objects of the selected
class.
IP address filters
IP address filters include only those messages with the client IP addresses
included in the filters set for this target.
Log targets can also execute a CLI command upon the appearance of an event
trigger. Events with a particular log message ID (such as Ox011300006, which
indicates failure to establish a backside connection) trigger the execution of a
given CLI command. Event triggers are typically used to immediately capture
system state information, execute a packet capture or generate an error report.
Note: Each log target maintains a fixed queue of log events to process. If the
arrival rate of messages exceeds this queue, the target may drop messages.
Navigate to Status Logging Target to view the number of processed,
pending, and dropped events. If this number is large, examine the subscription
list.
Administrators can create any number of log targets. More than one log target
can subscribe to the same events.
This message will be caught by any log target subscribed to the my_category
event type with a priority of notice or higher. This flexibility makes it possible to
include exactly the information desired in a log message.
This action can use any supported protocol to send its payload to a destination,
including HTTP, HTTPS, MQ and JMS.
Note: If no destination value is provided, the Log Action sends it’s payload to
the standard event logging system. To ensure reliability, it is necessary to
supply a valid destination.
A processing policy containing this action will only continue forward if the Log
Action can successfully send its payload to the destination given. If the action
cannot succeed in this manner, an error occurs.
This action will also wait for the configured amount of time (in this case the
default timeout value for the URL used) to receive a reply. If no reply is received,
the processing policy then continues to completion. The action does not make
the response available for further processing.
Like the Log Action, the Results Action will cause an error if the attempt to send
its payload to the configured destination fails. Like the Log Action, the Results
Action will wait for a response for the standard timeout amount of time, if the URL
given for the destination expects a response (such as with MQ).
Unlike the Log Action, the Results Action will cause an error if a response is
expected and none is received within the timeout amount of time.
The device can generate a large volume of log messages in a short amount of
time when under load. This can make the log messages sent by the device to
a remote server overload that server. When this happens, the DataPower
device can begin to slow down as well.
Event log messages cannot exceed 2 Kbytes in size. Messages larger than 2
Kbytes are truncated.
Using the Log Action or the Results Action in asynchronous mode can result
in excessive resource utilization when the destination becomes unresponsive.
Use of asynchronous mode should be avoided if possible.
It is possible to execute CLI commands on the device when particular log
messages are caught by a Log Target with an appropriately configured Event
Trigger. This capability allows administrators to automatically generate error
reports, run packet captures or even quiesce services with no human
intervention. This is very useful during heavy load testing or production
environments.
Some DataPower devices do offer hard drive storage (an option). These hard
drives can be used for log files. The persistent storage and larger capacities
of the hard drives allow for the creation of larger log files on the device itself. If
network latency or processing latency is a concern, consider using hard drive
storage for logging. Even when using a hard drive, log files must still be
rotated.
domain to more readily identify problems that could cross domain boundaries.
For example, when an MQ Queue Manager fails or an ODBC connection fails
with just a “connection failure” error message in the application domain, the
default domain log can show any network, interface, DNS, or other errors that
might have affected the connection.
To achieve this configuration, set the Identical Event Detection radio input to On
(the default is Off). In the Event Suppression Period field that then appears, enter
a value to indicate a suppression period (the default is 10 seconds). Only one
instance of identical messages will appear in the logs every 10 seconds. Use a
lower suppression period value if this does not meet the enterprise requirement.
Using a Load Balancer increases the availability of the logging servers, thus
reducing the likelihood that the logging system will become backed up and slow
down the device. This becomes particularly useful when the logging system is
using TCP to deliver log messages to a destination server. If that server
becomes unresponsive and the logging rate is high, the device can consume its
protocol stack resources.
messaging allows. When this happens, consider using the older, UDP-based
Syslog service.
The event logging system offers the ability to encrypt log messages before the
messages are sent off the device, which may meet the privacy requirements that
apply. For transaction logging, or any logging that contains a copy of all or part of
messages flowing through the device, it may be necessary to encrypt the
message content before using an action to send the message off the device.
Enable Feedback Detection when configuring the log target to suppress all log
events from the logging subsystem and prevent resource contention.
The WebSphere DataPower B2B Appliance builds upon the functionality in the
WebSphere DataPower Application Integration Appliance by adding trading
partner profile management, B2B transaction viewing capabilities and industry
standards based B2B messaging protocols to the already robust integration
capabilities of the core appliance. These three key capabilities are at the heart of
the B2B appliance. They are designed in such a way that the B2B appliance is
positioned very well to handle simple partner connections with data passing
through directly to end applications for further processing. If more complex data
flows are required the application integration capabilities of the B2B appliance
can be used to perform data validation, transformation, rules based enforcement
and content based routing.
The components that make up the B2B Gateway Object in the XB60 are depicted
in Figure 7-1.
B2B Appliance
B2B Gateway
Service
Partner Connection External Partner
Front Side Handlers Destinations
Partner
Profiles
Metadata Document
Store Store
(DB) (HDD)
B2B Viewer
internal and external B2B messaging and integration needs to reduce duplication
of effort and the increase speed of 'externalizing' internal processes. The
appliance model enables strong B2B business value by accelerating the pace of
innovative value-creating processes and strategic initiatives. You can utilize B2B
services to quickly and securely connect to your external partners and integrate
the partner connections to your application integration flows, all in a purpose built
hardware solution.
Figure 7-2 depicts how the WebSphere DataPower B2B Appliance utilizes B2B
services and A2A services together to provide a robust and complete B2B
integration solution.
B2B Integration
Services Services
• Partner Provisioning • Protocol Bridging
• Community • Content-based Routing
Management • Any-to-Any
• Non-Repudiation Transformation
Firewall
Firewall
Network Services
• IP Address Filtering / Host Aliasing
• VLAN Support / Standby Control
• Packet Trace / SNMP Traps
The archive process removes both copies of messages and message metadata.
Archived data cannot be imported into the appliance and cannot be viewed
through the Transaction Viewer.
Note: B2B payloads can optionally be stored off device to either a NFS mount
point or on an iSCSI device attached to the network.
Metadata storage
Metadata from each transaction is held on the appliance in the persistence store,
which is on the unencrypted part of the hard disk. This space can be shared with
configuration and log files if the appliance is otherwise configured to use the
local:///ondisk/ directory. The default setup does not use the hard disk for
anything besides B2B message contents and metadata. The B2B Persistence
object can be accessed by device administrators in the default domain. Its
Storage Size parameter controls the size of the persistence store. The default is
1GB to allow other use of the hard disk. The size can be safely increased to 64
GB.
Calculating capacity
To properly plan for archiving and the persistence store size, you need to
estimate the traffic characteristics for your appliance.
How many documents do you expect to receive per day and over what
number hours (peek)?
How large, on average, do you expect these documents to be?
Payload storage
For illustrative purposes, assume 10,000 EDI messages per day with an average
size of 10 KB. Therefore, you are expecting 100 MB of content per day. This
capacity requires 360 MB of document storage per day, which equates to
approximately 84 days.
Metadata storage
If the messages per day are split evenly between inbound and outbound and that
every outbound message requests an asynchronous MDN, the space for
metadata storage adds up to 15,000 transactions per day, which equates to 60
MB (15000 * 4 KB) of metadata storage per day. At the default 1 GB persistence
store size, this will fill in approximately 16 days. If the persistence store is
increased to 64 GB, over 1,000 days of message metadata can be persisted.
Using the default persistence store size in this example, setting the Archive
Document Age property to 7 days will remove document metadata from the
persistence store before it fills.
WebGUI controls
Each B2B Gateway object has an Archive tab. Each gateway can be
independently configured to archive documents and metadata off of the
appliance before purging or to purge without archiving.
#top
#service show b2bp encrypted-space
#service show b2bp size
The service show b2bp encrypted-space command shows how much of the 70
GB encrypted disk space the message contents has used.
The service show b2bp size command shows how much space message
metadata has used in the persistence store.
B2B Appliance
3 B2B
B2B Metadata
Storage Viewer
Synchronization
Real-time Data
Applications
Partners Active/Passive
Partners Standby Control
Partners B2B Payload
Storage
4 B2B Appliance
B2B
B2B Metadata
Storage Viewer
Standby Control must be configured on the ethernet adapter being used for data
transfer with both the primary and secondary device and both devices in the
standby group need to be set to a priority of 100. This will create a Virtual IP
(VIP) address that is shared between the two devices in the Standby Group. The
primary device receives data over the VIP, if a failure condition arises the
secondary device takes over the VIP and starts to receive data.
Best practices
The best practices listed in this section are unique to this use case, however any
best practices that exist related to the DataPower platform and or deployment of
the B2B appliance also apply.
B2B Payload Data for each B2B Gateway should be stored off device to a
shared directory (NFS or ISCSI). The storage system can be placed either in
the DMZ or protected zone depending on your security requirements. If
deployed in the protected zone it is recommended to isolate one of the
ethernet controllers to the connection and open the appropriate ports through
the inner firewall only from the B2B appliance.
– Use the same file location for all B2B Gateway Services; each file
persisted for non-repudiation is uniquely named and preceded with the
serial number of the device
When configuring the B2B persistence High Availabilitiy tab be sure to use the
same virtual IP addresss that you configured in Standby Control for the
Ethernet interface being used for external connections.
Pollers should not be configured in the B2B Gateways of either the primary or
secondary device; they should be configured in a Multi-Protocol Gateway that
outputs to the virtual IP Address being used for connectinons from external
partners. This ensures that the metadata store on the secondary device does
not receive active data from pollers.
The B2B Gateways and Multi-Protocol Gateways (used for pollers) should be
configured identical on both the primary and the secondary devices.
If using a standby group on the Ethernet interface that is being used for the
internal network connection, it is recommended that you use a Multi-Protocol
Gateway service to route all transactions originating from the internal network
into the virtual IP address associated with the B2B Persistence HA
configuration. The best way to do this is to set the output of the Multi-protocol
gateway to point to the a HTTP front-side handler in the B2B Gateway
service.
Sharing the same configuration between the two devices is recommended.
the most basic way to do this is to export the configuration from the primary
device and import it into the secondary device using deployment policies on
the secondary device to change any settings specific to the secondary device
(e.g. host names, IP addresses, etc.). More information about configuration
management techniques and options can be found in Chapter 9,
“Configuration management and deployment” on page 191.
Limitations
The limitations listed in this section are unique to this use case, however any
limitations that exist related to the DataPower platform and or deployment of the
B2B appliance also apply.
When B2B payloads are stored off of the device they are not encrypted, it is
the responsibility of the network security team to adequately protect all data
stored on external Storage Area Networks and/or file servers.
The passive device is sitting idle until fail-over occurs; The passive system
should have an identical configuration as the primary; any usage of the
passive system will cause the configuration to be out of sync.
This solution only provides fail-over and does not provide additional
throughput like an active/active configuration does.
There will be a 1 to 3 second delay during the switch over to the secondary
device depending on the network latency of your network.
Both the primary and secondary device must be installed on the same
network subnet.
Pollers must be configured outside of the B2B Gateway service in
pre-processing service that bridges the polling protocol to a http.
Multiple passive devices are not supported; this configuration only supports a
two device configuration.
B2B Appliance
3 B2B
B2B Metadata
Storage Viewer
1
Applications
Partners
Partners
Partners B2B Payload
Storage
B2B Appliance
1
3
B2B
B2B Metadata
Storage Viewer
Best practices
The best practices listed in this section are unique to this use case, however any
best practices that exist related to the DataPower platform and or deployment of
the B2B appliance also apply.
B2B Payload Data for each B2B Gateway should be stored off device to a
shared directory (NFS or ISCSI). The storage system can be placed either in
the DMZ or protected zone depending on your security requirements. If
deployed in the protected zone it is recommended to isolate one of the
ethernet controllers to the connection and open the appropriate ports through
the inner firewall only from the B2B appliance.
– Use the same file location for all B2B Gateway Services; each file
persisted for non-repudiation is uniquely named and preceded with the
serial number of the device.
Archive B2B Gateway transactions often using the automated archive
capabilities of each B2B Gateway service; if any device should fail, the
metadata on that device will not be accessible until you restore the machine
or place the hard drives into a replacement device.
Sharing the same configuration between all active nodes is recommended.
the most basic way to do this is to export the configuration from the primary
device and import it into the secondary device using deployment policies on
the secondary device to change any settings specific to the secondary device
(e.g. host names, IP addresses, etc.). More information about configuration
management techniques and options can be found in Chapter 9,
“Configuration management and deployment” on page 191.
The B2B payload portion of the local hard drives are encrypted at the time of
first initialization. If using an active/active deployment and storing the B2B
payloads externally, IBM recommends you disable the encryption on the local
drive so it can be used for other functions. information on how to disable the
AES encryption can be found in the B2B appliance documentation.
Limitations
The limitations listed in this section are unique to this use case, however any
limitations that exist related to the DataPower platform and or deployment of the
B2B appliance also apply. When passing data from a load balancer to multiple
front-side handlers associated with any B2B Gateway service configured on each
device, the following limits and advice should be taken into consideration.
When B2B payloads are stored off of the device they are not encrypted, it is
the responsibility of the network security team to adequately protect all data
stored on external Storage Area Networks and/or file servers.
MDN state is not monitored across multiple devices. When using B2B
messaging protocols you must only use synchronous Message Disposition
As a result, significant effort has been made within the software industry to
produce standardized frameworks that outline the development, testing, and
release life cycles for projects to minimize this risk. These frameworks or
methodologies are implemented by many IT organizations and share common
development, deployment, and testing principles.
This chapter discusses the features, considerations, and best practices for
implementing DataPower appliances within a life cycle based implementation. It
includes the following topics:
Organizational structure
Software development life cycle
DataPower life cycle stages
A common misconception is that the “all in one” nature of the device necessitates
a single group or individual owning and executing all aspects of the development
and management life cycle. It is possible for a single group to own the end-to-end
responsibility for executing all DataPower solution tasks; however, the breadth of
knowledge that is required across technology disciplines makes this type of
structure impractical within most organizations.
In the absence of a defined DataPower appliance team that can gauge the
suitability of using the appliance for new projects, it is important to establish
guidelines for use within the enterprise. Guidelines help to avoid implementations
that are not in line with the original design intent of the product or that conflict
with the organization’s desired role for the DataPower device.
Requirements
Design
Development
Testing
Deployment
Although a detailed discussion of the specific activities that are associated with
DataPower development is beyond the scope of this book, project managers can
expect the high-level tasks that we discuss in this section to be executed in a
conventional DataPower project.
Roles for this task include the Network Administrator, Systems Operator, and
Operations Personnel.
Roles for this task include the Architect and Operations Staff.
8.3.4 Development
For DataPower users, development usually entails configuration through the
web-based graphical user interface (WebGUI) and construction of associated
artifacts. The actual development activities vary from project to project, but in
most cases development includes the following activities:
Configure messaging listeners and services (for example, HTTP Front Side
Handlers and WS-Proxy services)
Configure messaging policies that define how to manage or manipulate
in-flight messages
Construct integration and security artifacts, such as XSL templates
Test the solution during development
8.3.5 Testing
The testing or quality assurance stage in a DataPower solution is identical to a
software project testing stage. The only difference for a DataPower project is that
the solution is deployed on hardware instead of a software platform. As with any
project, testing includes the following activities:
Construct test cases
Execute test cases
Record issues
8.3.6 Deployment
Throughout this book, we discuss strategies for configuration and firmware
deployment. At a high level, DataPower deployment includes the following tasks:
Deploy the firmware
Deploy the configuration
Configure the environment
The role for this task includes the Operations Staff
There are many SCM tools available on the market today. Most organizations
have a favorite (or in some cases a mandated) SCM tool. An effective SCM tool
provides support for file versioning, parallel development, audit trails, and
integration with development and deployment tools, IBM Rational ClearCase® is
an example of a popular software configuration management tool that provides
this type of functionality.
It is important to note that there can be multiple SCM tools in use at the same
time within a single organization. For example, a development team might use a
robust enterprise product for control of source code, while an operations team
might maintain a home-grown tool for control of compiled application releases.
This type of variation is often a result of the differences in function, budgets, and
culture between teams.
Development assets
Deployment packages
System-level configuration
As a general rule, system-level configuration covers configuration that is defined
within the default domain of the device. For example, the network card
configuration, device name, NTP settings, DNS settings, and role-based
management settings are all system level configuration items that an
administrator should store in a revision control system. This type of configuration
is the least likely to change over time, but it is worthwhile storing this information
in a change repository in case a device ever needs to be replaced or
reconfigured from an initial state.
A revision control process for system-level data can be as primitive as the use of
a spreadsheet with all of the relevant system information stored within. However,
a simpler and more reliable method is to use the Backup Configuration function
to retrieve a compressed file that contains the system-level settings of the
device.This backup file can then be stored and versioned as a file within an SCM
tool.
Development assets
Development assets on a DataPower appliance project include the XML, XSLT,
WTX, WSDL, and XSD files that are used within a processing policy. Although
these assets can be exported from the device as part of a system backup or
domain export, it is prudent to manage each file individually within an SCM tool
so that changes to the files can be tracked atomically. This tracking allows for
individual files to be versioned as changes are made during the development
stage and before the entire project reaches the checkpoint or is labeled for
release into the next SDLC stage.
Deployment packages
Although revision control of the atomic development assets is useful in a
development environment, it is more practical to manage a complete deployment
package when migrating to testing and production environments. In the
DataPower appliance context, this type of management means using the Export
Configuration function to generate a compressed package and storing the entire
package in the repository. This function provides the deployment team with a
history of deployment packages within the repository and ensures that a domain
can be returned to a versioned state by importing the appropriate package.
Development System
RCS RCS
Development System
Assets Backup
Deployment
Deployment RCS
Package
Development
Developer
Development
WSDL
2. Check in Assets
XSLT
Developer Code Repository
DP
Export
Team Lead
Deployment
Package
1.0
Build Repository
4. The deployment team retrieves the 1.0 project from the build repository and
deploys it into the QA environment, as shown in Figure 9-5.
QA
4. Deploy to QA
Build Manager
Deployment
Package
1.0
Build Repository
QA 1.0
Tester
5. Found Bug!
6. The development team resolves the issue and the team leader checks in a
new version of the configuration to the build repository with the label 1.1 as
the checkpoint for the package, as shown in Figure 9-7.
Development
Build Repository
7. The QA team executes testing on the newly deployed 1.1 configuration and
gives it the green light, as shown in Figure 9-8.
QA
Build Manager
Deployment
Package
1.1
Tester
Build Repository 7. All tests passed
8. The project manager notifies the deployment team that the package is now
ready for implementation to production and a change window is scheduled, as
shown in Figure 9-9.
GO!
9. The deployment team retrieves the 1.1 version of the configuration from the
build repository and deploys it into production, as shown in Figure 9-10.
Production
Operations
Deployment
Package
1.1
Build Repository
In this manner, the development team can make configuration changes only on
their own devices, and the testing and production teams have absolute certainty
about the changes that are applied to their respective environments. A full history
of releases is maintained, and previous builds can be retrieved and examined if
required.
Code Developer
Developer
Developer
However, most tools now support parallel development through the advent of
code branching, textual merging, and in many cases the elimination of the lock
concept entirely as shown in Figure 9-12.
Code
Code
Code
Code Developer
Developer
Developer
The classic target of parallel or concurrent development is source code files. For
example, in a C++ based software development project, multiple developers
might need to modify the same C++ source code file at the same time and
resolve conflicts when checking the file back into the source code repository.
Although the practice of concurrent development can work well for traditional
software development projects, applying this practice to DataPower appliance
development can be a challenge. With the DataPower appliance, the
configuration instructions for messaging and security policies are not contained
within atomic text-based files. Instead, the DataPower device allows users to
export configuration as an XML file contained within a compressed package,
which makes it difficult to apply most of the automated merge and resolve
functionality on which concurrent development projects rely.
In fact, most DataPower users find that the advantages of parallel software
development do not translate well to an appliance-based solution. Configuration
of a DataPower device takes less time to implement, requires fewer developers,
contain fewer bugs, and changes far less than traditional code based
development. These advantages result in a shorter development life cycle, which
offers far less return on the cost of managing a parallel development practice.
One approach allows individual developers to work in their own domains with a
configuration that is exported from the SCM tool. Environment-specific values,
such as IP addresses and ports, might need to be modified for each domain, but
the actions and the order of operations within the processing policy should
remain the same.
DataPower configuration file; however, both approaches will likely require manual
correction to address any conflicts or unintended errors that arise after the
merge. Figure 9-13 illustrates the use of domains and merging to support a
parallel development methodology.
Domain A Domain B
Test Domain
1. Make changes
2. Merge and
Test 4. Refresh domains
with updated config
Developer A
3. Check in changes
Code Repository
9.2 Deployment
Deploying a DataPower appliance configuration into a production or testing
environment is an important step in the life cycle and should always be executed
in a well thought out manner. Although the DataPower appliance is designed and
built to support rapid changes to configurations during development, it is
important to deploy those changes in a way that is both repeatable and
reversible. Fortunately, the device provides built-in functionality to facilitate
controlled deployment of configuration packages.
Ultimately, your organization might choose to move forward with domain deletion
or a domain reset as part of the deployment process. If this is the case, ensure
that the device is removed from active use before executing the deletion. Starting
with firmware version 3.8.1, DataPower products provide a quiesce function that
gracefully disables a configuration object. See 9.2.5, “Hot deployment” on
page 213 for details.
The Multi Protocol Gateway, WS-Proxy, B2B Gateway, Low Latency Messaging,
and XML Gateway are all service objects within DataPower configurations.
Without these top-level service objects, no messages can be processed, routed,
or handled. Service objects define relationships to many other configuration
objects, in particular Front Side Handlers, XML Managers, and Processing
Policies as shown in Figure 9-15.
The Front Side Handler object defines how messages are received on the front
side of the appliance. For example, an HTTPS front side handler defines the IP,
Port, and SSL credentials that the device uses when listening for incoming
messages. Among other things, the XML manager object defines the rules and
limits for XML parsing. Finally, the processing policy describes what happens
when messages are received through the processing actions that are defined in
its child, the processing rule object. See Figure 9-16.
SSL Policy
Processing Policy XML Manager
The beauty of this design is that an object can become an active part of message
processing only if it has a relationship with a parent service or one of its
descendents. Thus, orphaned objects cannot impact message processing. In
other words, if a configuration object is inadvertently orphaned and left in a
domain after a change is applied, the orphaned object has little chance of
impacting the new configuration. See Figure 9-17.
SSL Policy
Processing Policy XML Manager
Alternatively, the administrator can define name resolution rules in the Host Alias
section of the default domain on the appliance. The Host Alias operates similarly
to the DNS protocol, except there is no call made to a DNS server. Instead, the
DataPower device uses the local name resolution table to resolve the host name
to a physical address.
When taking this approach, it is crucial that post deployment changes be made in
a repeatable, auditable, and reliable way. This method implies that some form of
automation is necessary and that the replacement values must be stored and
versioned in a repository.
It is extremely important that the value modification solution is well thought out in
order to mitigate the risk of introducing unexpected problems into a critical
environment. Due to the level of diligence required, it is often the case that post
deployment value modification solutions have a fair degree of complexity in
planning, creation and maintenance of the solution.
Predeployment modification
The flip side of post deployment modification is modification of a configuration
package before it is deployed to the target device, which can take one of the
following forms:
Modification of values on a DataPower device prior to export (for example, a
development team might replace a back-end destination value of
http://mylaptop:8080/test with http://www.service.com/op1 prior to
exporting the configuration from the device)
Modification of the deployment package after exporting it from the device (for
example, the use of an XSLT transformation to replace the back-end
destination in the export.xml file that is contained in the export package)
Modification of a remote configuration file (see Chapter 3, “Domains” on
page 59 for additional information)
Deployment policy
The Deployment Policy object is designed and developed specifically to address
the issue of modifying fine-grained DataPower configuration values for
environments. As such, it provides easy to use and deep functionality for
modification of values and can be referenced when importing a configuration
package.
The Deployment Policy object is a powerful tool and is easy to use, but it was not
designed to support the modification of coarser grained configuration objects.
When judging the suitability of the deployment policy it is worth remembering that
it can only act on name-value pairs. For example, suppose that a DataPower
configuration contains a Matching Rule action for requests that end in the URI
/Jay as shown in Example 9-1.
A deployment policy can be created to modify the URL property of the matching
rule so that it is changes to the value /Ratna as shown in Figure 9-18.
Matching Matching
MatchRules MatchRules
Url="/Jay" Change URL to "/Ratna" Url="/Ratna"
deployment, the DataPower configuration file would look similar to the XML
snippet shown in Example 9-2.
However, it would not be possible to create a deployment policy that can add new
MatchRules to the action (that is, it is not possible to add a rule to match on
/Ratna in addition to the /Jay match). This configuration is not possible with the
deployment policy because a MatchRule is a complex configuration item with
multiple name-value pairs. See Figure 9-19.
Matching Matching
MatchRules MatchRules
Add New MatchRule
Url="/Jay" Element Url="/Jay"
MatchRules
Url="/Ratna"
Externalizing values
A final method for dealing with environment-specific values is to externalize the
data from the DataPower appliance. For example, a DataPower processing policy
package can reference an XML-based routing table that contains a list of
back-end destinations. If this routing table file is retrieved from an external source
(such as a web server), the DataPower configuration can be deployed without
any changes as long as the appropriate resource file is available.
One of the main advantages of this approach is that these values can now be
modified without making any changes to the DataPower processing policy or
service objects. In fact, this is a useful design pattern in general and is an easy
way to minimize the amount of change required on the device itself.
It is important for the external files to be stored in a revision control system along
with the associated DataPower configuration so that the environment can be
recreated when necessary. In addition, be aware that DataPower policies must
be configured to use externalized values. No action (without modification)
automatically performs this function.
http://www.ibm.com/developerworks/websphere/library/techarticles/0801_r
asmussen/0801_rasmussen.html
Although DataPower products are not designed to offer an enterprise solution for
storing and securing private key material, they do store private key files in an
encrypted, write only file system for internal use. Thus, after a private key file is
uploaded, imported, or created on a DataPower device, it is almost impossible to
view or download that cryptographic material.
Private keys: It is essential that private key files are stored in a reliable,
secure repository within your organization. The DataPower appliance is not a
key storage or distribution system and should not be used as a key repository.
At one time, managing the redeployment of private key files for DataPower
disaster recovery was a challenge for administrators. However, the recent
improvements provided in firmware version 3.8.1 make the process much easier.
Now, administrators can simply export the entire contents of the device including
the private key material and store the package in a reliable repository. The key
files remain secure because the backup package is encrypted using the public
certificate specified by the user. For specific details about the secure backup
function, consult the Administrator’s Guide in the online IBM DataPower
Information Center.
Although this solves the issue of key deployment for backup and recovery, those
organizations who choose to deploy configurations by first wiping out the target
application domain need a mechanism for redeploying the private key files to the
DataPower appliance. One solution is to avoid deleting the application domain
and instead adopt a policy of overwriting changes as described in “Overwriting
existing configuration” on page 202. If this method is not possible, an
administrator can either re-import cryptographic material or store the files in the
sharedcert: directory.
Because the sharedcert: directory is shared across all domains, special care
must be taken with the names of the files to ensure that there are no conflicts. it
is also advisable that key and certificate files be password protected due to the
fact that they will be accessible within all domains.
Provided that the team had the forethought to use a checkpoint, the roll back
feature can be a time saver when backing out a project change. For details about
the use of the domain checkpoint functionality, consult the Administrator’s Guide
in the DataPower product documentation set.
Details on the quiesce feature can be found in the Administrator’s Guide within
the IBM DataPower Information Center.
10
This provides for automation possibilities that are limited only by the end user’s
desire to reduce hands on operation.
Repeatable processes
A benefit of building an automated system is that the set of defined instructions
are both repeatable and auditable. Having a truly repeatable process means that
behavior is predictable and results achieved when testing a process are more
Restricting access
Not only does automation allow organizations to reduce the number of errors
resulting from human operation, it also allows them to restrict the type of access
that is allowed to critical systems. For example, a human operator with an
administrator account can invoke a broad range of management functions, while
a human operator with access to an automation system can only invoke the
functions that have been automated. Provided that the automation system itself
is secured, an automated system provides a reduction in the risk that
unauthorized changes will be made to the target system.
Reducing specialization
Reducing the level of human interaction can also mean reducing the level of
specialization required to operate a system. For example, a user may require a
certain level of product experience and skill to retrieve memory and CPU
utilization from a group of production servers. This dependency on skilled
resources limits the availability of the information and can ultimately increase the
overall cost for maintenance of the system.
One-off tasks
While it may seem obvious that tasks destined to be executed only once or twice
are not candidates for automation, there are occasions where a lack of foresight
can result in a wasted investment of effort for a task that rarely gets executed. An
example would be a script that creates user accounts for an environment that will
only ever have a single account.It is important to gain an understanding of the
frequency with which a task may be executed prior to spending the effort
required to automate it.
At inception this script might provide immediate value - reducing the time
required for the middleware team to release an encrypted messaging proxy and
minimizing the level of expertise required. However, if new users demand
additional options to meet their own specific requirements, the complexity of the
script will rise until it becomes more complex than the original activity it was
meant to simplify.
For example, suppose that a build manager is assigned the task of regularly
monitoring the system metrics of a DataPower device hosted in a development
environment:
In order to address the requirement and save himself the effort of manually
retrieving the data, the build manager builds a script that queries the system
metrics of the device and appends the results to a local file (Figure 10-1). In
order for the script to be called regularly, he deploys the script on a
development server so that it can be executed every 30 minutes. Because he
will not be manually running the script herself, the build manager hardcodes
the administrator username and password into the script so that the
authentication requirement can be successfully fulfilled.
Development
In this scenario, there are a few potential risks that the build manager may have
inadvertently exposed (see Figure 10-2):
The script has a hard coded password in it - this means that anyone who
gains access to the script will be privy to the authentication data required to
login to the appliance.
If other users are able to access to the script, they may be able to create
additional user accounts or modify the configuration by simply changing the
commands contained in the script.
If the network has not been segregated with IP firewalls, a typo in the device
destination may impact a production or testing device.
Development
Production
?
WS-Management
WSDM
SOMA
AMP
XML Management Interface
HTTP
TCP/IP
POST to:
https://device-ip:5550/service/mgmt/app/1.0
Automation System
Manager
XML
WS-Management
WSDM
SOMA
AMP
XML Management Interface
port 5550
DataPower
Figure 10-4 An automation system utilizing the XML Management Interface for an AMP
message.
10.3.1 Authentication
As with all DataPower administrative interfaces, automation systems that utilize
the XML Management Interface must provide credentials for authentication. XMI
authentication uses the same credential store and Role Based Management
(RBM) rules as the CLI and WebGUI interfaces. The administrative username
and password is transmitted over a secure HTTPS connection via basic access
authentication.
Example 10-1 shows the format of an HTTP basic access authentication header.
Note: If you are manually creating your credential string for encoding, make
sure that there are no CR or LF characters at the end of the credential string.
An encoded string that ends with “Cg” is a strong indication that the clear text
string ended with a newline character.
For example, to authenticate with the XML Management Interface using the
username ‘Ashy’ and password ‘supplies’, concatenate the username and the
password separated by a colon as shown in Example 10-3 on page 223.
Next, the raw credential string is encoded using the base64 algorithm to produce
an encoded version of the credentials as shown in Example 10-4.
Finally, the HTTP header is set as specified in the HTTP access authentication
scheme with the base64 encoded credential data and a token as shown in
Example 10-5.
The HTTP Basic Authentication scheme is a well known and popular standard for
transmitting credentials. Most tools, programming languages and scripting
platforms will already provide facilities for generating the HTTP headers required
based solely on username and password credentials, thus minimizing the effort
required to build an automation solution.
Usage
AMP is exposed on the DataPower appliance as a web service with a WSDL that
describes the service, operation and message elements for AMP commands.
The app-mgmt-protocol.wsdl and associated app-mgmt-protocol.xsd files are
available for download and are located on the appliance’s filesystem within the
store directory.
AMP request messages are transmitted to the XML Management Interface over
the HTTPS protocol and response messages are returned over the same
interface. The format of the request and response messages are described in the
WSDL and are designed to be used by WSDL aware tools to quickly generate
AMP messages. The sample AMP message shown in Example 10-6 illustrates a
request message that retrieves the list of domains from a DataPower appliance.
After receiving the preceding AMP request message, the DataPower appliance
will return a response shown in Example 10-7.
The AMP API provides a set of operations that are useful for administration of
firmware, determining global settings and administration of domain
configurations. However it does not provide full coverage of all DataPower
administrative and system funcitons.
A key difference between AMP and SOMA is that IBM makes no guarantee that
SOMA operations and message formats will remain the same between firmware
releases. This means that automation systems need to be regression tested as
part of a firmware upgrade process if they utilize SOMA operations. In practice,
the SOMA protocol has changed very little from release to release - however it is
important to understand that changes to the SOMA API is a realistic possibility.
Usage
As with AMP, the SOMA messaging protocol is implemented as a web service
with WSDL and XSD files describing the service available for download from the
DataPower device’s internal filesystem.
There are two versions of the SOMA API available on the 3.8.1 version of
firmware located in the store directory:
xml-mgmt.wsdl
xml-mgmt-2004.wsdl (deprecated)
In addition, the SOMA service utilizes the following schema files located within
the store directory:
xml-mgmt-base.xsd
xml-mgmt-ops.xsd
xml-mgmt.xsd
Example 10-8 shows a SOMA request message that retrieves the memory
utilization on a particular DataPower appliance:
</env:Envelope>
Given the SOMA request identified above, the appliance will respond with a
message similar to that in Example 10-9.
The power of SOMA is its broad range of administrative functions. Almost every
function exposed through the Web GUI and CLI interface is also available within
the SOMA catalog making it an ideal interface for fine grained task automation.
However, due to the wide variety of administrative commands that are supported,
the operations themselves tend to be defined abstractly and it can be difficult to
identify the correct syntax to achieve a desired result. Users may need to consult
the xml-mgmt.xsd file (available on the DataPower appliance filesystem) for
specific enumeration values when using the following SOMA operations:
The WSDM standard is split into two major categories: Management Of Web
Services (MOWS) and Management Using Web Services (MUWS). The intent is
for MUWS to be used for manageable resources (for example, the management
of a printer), while MOWS extends MUWS with additional functionality for
managing web services.
For DataPower devices, these management interfaces are mainly used for
monitoring system and web service metrics. Details on using the WSDM
interface can be found in the DataPower Administrator’s Guide
Client System
WAMT
The value of WAMT is in its set of coarse grained operations that represent
typical DataPower management functions. Under the covers, WAMT is calling the
set of finer grained management functions that comprise the AMP and SOMA
messaging protocols within the XML Management Interface - however these
details are hidden from a WAMT user.
While the feature set is deep, WAMT is not actually intended for human use and
there is no GUI or human operator interface provided. Instead, all WAMT calls
are made within a Java Virtual Machine (JVM).
10.4.1 Usage
The WAMT API can be used by any application or system capable of invoking the
java classes provided in the WAMT jar packages. This can include:
custom Java GUI applications
third party management applications with Java based extensibility
ANT build tasks
Jython scripts
non java applications that leverage a Java Native Interface (JNI) bridge. (see
http://www.ibm.com/developerworks/java/tutorials/j-jni/ for details on
using JNI).
WAMT operations are particularly useful for developers, administrators and build
managers who are looking for a custom, automated DataPower management
solution. An classic example of WAMT usage would be the creation of an ANT
task that uploads files to a device as part of a build management script.
Users can consult the javadoc included with the WAMT package for a complete
reference of operations that are available. At a high level, the WAMT
management functions are similar to the ones exposed by AMP and include
operations for domain management, disaster recovery and device
synchronization.
Note: The CLI interface is not designed for automation and there is no
guarantee that the interface will remain the same. Users should be aware that
it is possible for support, syntax and results of commands to differ between
firmware releases.
10.5.1 Authentication
The CLI uses the same authentication scheme and credential store as the XML
Management and Web GUI management interfaces. Users must enter their
username and password in order to be authenticated by the DataPower
appliance prior to executing any management commands.
10.5.3 Usage
As part of the initial DataPower installation an operator will need to access the
CLI via a direct serial port connection. During this time, the operator will assign
an IP addresses to one or more of the network cards and choose to enable the
web GUI and ssh management interfaces. Upon completion of this initial setup all
CLI management should be done remotely via the SSH protocol. There is also
an option to expose the CLI over the telnet protocol, however this is not a
recommended approach due to the non-secure nature of telnet.
For example, the following script prompts a user for a password, logs in to a
remote DataPower appliance and retrieves memory usage statistics:
On execution, the preceding script will return a result similar to the following:
xi50#
Memory Usage: 14 %
Total Memory: 4149440 kbytes
Used Memory: 598201 kbytes
Free Memory: 3551239 kbytes
Requested Memory: 670956 kbytes
Hold Memory: 232011 kbytes
xi50# Goodbye.
>
CLI usage requires specific skill sets that may not be applicable to all DataPower
administrators.
10.8 Summary
Modern technology groups have an expectation that operations tasks related to
management and deployment of applications will be automated. DataPower
devices offer many different administrative interfaces in support of automation
and can fit well into existing automation environments.
The skill sets of the team, the tooling that is available and the functions that are
required will often dictate the specific interface and message protocol that will be
used.
The key to customizing these steps is a clear understanding of the input and
output contexts for the custom XSL templates. This appendix provides the details
needed to create either a custom authentication or credential mapping XSLT.
Authentication phase
The authentication phase is responsible for determining whether a user should
be granted access to the WebGUI or the command-line interface (CLI). A custom
authentication XSLT is responsible for inspecting the user’s identity and providing
a credential in return.
Input context
The input context to a custom authentication XSL contains the user’s extracted
identity and is shown in Example A-1.
Output context
The output context provides RBM with the authenticated user’s credential, or null
if authentication failed.
Input context
The input context to a custom credential mapping XSL contains the
authenticated credential and includes the XML shown in Example A-3.
Output context
The output of the credential mapping phase must be a list of access policy
strings as described in “Access policy statements” on page 8.
The LDAP organization is shown in Figure A-1. The left subtree shows how users
are organized, and the right subtree shows how domains and roles are
organized. An organizational unit (ou) is used to represent a DataPower domain
and a group of names (groupOfNames) is used to represent the various access
roles.
Table A-1 shows the various roles and their domain restrictions.
An XML file is used to define the various roles and their access policies.
Example 10-12 shows a fragment of the sample rbmTemplates.xml file. If a
template has a privileged attribute equal to true, then it can be associated only
with the default domain. The complete file can be found in this book’s associated
download files. Refer to Appendix B, “Additional material” on page 247 for
information on how do download the associated files.
Example 10-12 Partial listing of rbmTemplates.xml file that defines various roles
<rbm-templates>
<rbm-template name="developer" privileged="false">
<access-policy>*/DOMAIN_ID/*?Access=rwadx</access-policy>
</rbm-template>
.
.
.
</rbm-template>
</rbm-templates>
Step 1: Authentication
Because DataPower has built-in support for LDAP-based authentication, no
customization is required. Figure A-2 shows an example of the configuration
settings to authenticate the user against the LDAP server.
Example A-5 Required steps to map user credential to access policy strings
query the LDAP server for a list of groups to which the user belongs;
for each group found
parse the group’s DN to determine domain name and user role;
if the domain = ‘default’, privileged = ‘true’ else ‘false’;
find any template with name=role and matching privilege;
if a template was found
for each access-policy within the template
replace the domain placeholder with the actual domain name;
write the access policy string to the output context;
end-for
end-if
end-for
The output from the XSLT will be the list of access policy strings for the user’s
role or roles. Example A-6 shows the output for a user who is authorized to do
backups in domain1 and a developer in domain2.
Development considerations
This section provides some basic guidance to help with the development of XSL
templates for custom RBM processing.
Disable caching
Make sure to disable caching during the development and testing phases. By
default, DataPower caches RBM results. After the solution is deployed, you can
re-enable caching.
Select the Additional materials and open the directory that corresponds with
the IBM Redbooks form number, SG247901.
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this book.
IBM Redbooks
The following IBM Redbooks publications provide additional information about
the topic in this document. Note that some publications referenced in this list
might be available in softcopy only.
WebSphere DataPower SOA Appliance: The XML Management Interface,
REDP-4446-00
IBM WebSphere DataPower SOA Appliances Part I: Overview and Getting
Started, REDP-4327-00
IBM WebSphere DataPower SOA Appliances Part II: Authentication and
Authorization, REDP-4364-00
IBM WebSphere DataPower SOA Appliances Part III: XML Security Guide,
REDP-4365-00
IBM WebSphere DataPower SOA Appliances Part IV: Management and
Governance, REDP-4366-00
You can search for, view, or download Redbooks, Redpapers, Technotes, draft
publications and Additional materials, as well as order hardcopy Redbooks
publications, at this Web site:
ibm.com/redbooks
Other publications
These publications are also relevant as further information sources:
IBM WebSphere DataPower SOA Appliance Handbook, IBM Press © 2008,
ISBN 9780137148196
Online resources
These Web sites are also relevant as further information sources:
Monitoring WebSphere DataPower SOA Appliances
http://www.ibm.com/developerworks/websphere/library/techarticles/100
3_rasmussen/1003_rasmussen.html
Managing multiple DataPower Appliances with the WebSphere Appliance
Management Toolkit, Part 1: Introduction to the WebSphere Appliance
Management Toolkit
http://www.ibm.com/developerworks/websphere/library/techarticles/101
1_burke/1011_burke.html
Managing multiple DataPower Appliances with the WebSphere Appliance
Management Toolkit, Part 2: Scripting with the WebSphere Appliance
Management Toolkit
http://www.ibm.com/developerworks/websphere/library/techarticles/110
2_burke/1102_burke.html
Extending WebSphere DataPower with centralized appliance management
http://www.ibm.com/developerworks/websphere/techjournal/0809_roytman
/0809_roytman.html
Managing WebSphere DataPower SOA Appliance configurations for high
availability, consistency, and control, Part 1
http://www.ibm.com/developerworks/websphere/library/techarticles/080
1_rasmussen/0801_rasmussen.html
Managing WebSphere DataPower SOA Appliance configurations for high
availability, consistency, and control, Part 2: Application promotion strategies
hhttp://www.ibm.com/developerworks/websphere/library/techarticles/09
04_rasmussen/0904_rasmussen.html
WebSphere DataPower SOA Appliance performance tuning
http://www.ibm.com/developerworks/webservices/library/ws-dpperforman
ce/index.html
Managing WebSphere DataPower SOA Appliances via the WebSphere
Application Server V7 Administrative Console
http://www.ibm.com/developerworks/websphere/library/techarticles/100
3_das/1003_das.html
WebSphere DataPower SOA Appliances developerWorks library
http://www.ibm.com/developerworks/websphere/zones/businessintegratio
n/dp.html
Index
configuration functions 216
A for 216
access control 61
management functions 216
access control list 5
monitoring functions 216
access level 6
security considerations 219
Group-defined 6
task 216
Privileged 6
User 6
access policies 12 B
access policy statement 8–9 B2B
basic policy statement 10 Active/Active high availability 180
complex policy statement 11 Active/Passive High Availability 175
policy statement editor 11 appliance 168, 171
access profile 8 best practices 171, 178, 181
Active/Active high availability 180 capacity planning 172
Active/Passive High Availability 175 Gateway Service 169
Address Mask Reply 38 integration 168
Address Resolution Protocol 34 metadata storage 172–173
administering access 2 payload storage 172–173
Appliance Management Protocol 224–225 Transaction Viewer 172
advantages 225 use cases 174
disadvantages 225 Viewer 169
appliance team 185 B2B Gateway 202
application domain 60, 62, 67–69 backup 61
benefits 60 basic policy statement 10
configuration file 66 Best Effort Event Logging 157
empty 201 best practices
upgrading 201 B2B 171, 178, 181
application segregation 61 configuration management 214
application-level traffic 131 deployment 214
app-mgmt-protocol 224 domain 75
Audit log 154, 156 logging 163
audit log 24 networking 46
SOAP management interface 24 securing access 25
authentication 3, 5–6, 22, 237–238 SNMP monitoring 124
authentication server Standby Control 48
remote 18 build repository 195
authenticationFailure 82
authorization 5
autoconfig.cfg 66
C
capacity planning 62
automation B2B 172
against 218 certificate
authentication 222 replacement policy 124
command line interface 230 certificate monitoring 122
Index 257
7901IX.fm Draft Document for Review April 13, 2011 6:45 am
ITCAM for SOA DataPower data collector 131 writing to a remote server 155
ITCAM for SOA Platform 128 writing to local file or cache 155
ITCAM for Transactions 129 log messages
ITCAM for Virtual Servers 129 domain 66
iterative life cycle 186, 198 Email Pager 156
log target 63, 154–155, 157
create 158
L event filters 159
LDAP 18–19
IP address filters 159
group mapping 21
object filters 159
remotely defined group 18
SNMP 93
least connections 42
logging
life cycle stages 187
asynchronous mode 163
deployment 189
Audit logging 154
development 189
benefits 157
operational design 188
best practices 163
physical installation 188
confidentiality 165
solution design 188
domain 66
testing 189
Feedback Detection 165
line of business segregation 61
Message process logging 154
linkDown 82
usage 157
linkUp 82
usage considerations 162
listening address 46
logging system 63
Load Balancer 43, 164
logical segregation 61
algorithms
Low Latency Messaging 202
least connections 42
weighted least connections 42
weighted round robin 42 M
backend destination 41 MAC address 34
First Alive algorithm 40 management information base 80–81
Group 41–42 structure 81
Group Object 41–42, 45 management interface 50
health checking 44 Management Of Web Services 228
full service check 45 management roles 184–185
separate health check match 45 management traffic 46
service object Management Using Web Services 228
status 45 MapCredentials 14
simple TCP check 45 master administrator password 4
Round Robin algorithm 40 Maximum Transmission Unit 34
local domain 69 Memory Usage 102
Local Login as Fallback 26 MemoryStatus 103
local user group 7, 18 Message Content View 131
credential mapping 19 Message Flow Pattern 131
local user repository 13, 15 Message process log 154
pros and cons 13 event logging 154
Log Action 154, 157, 160–161, 163 transaction logging 154
log category 155, 162 message segregation 61
custom 162 Meta Data document 52
log message storage 155 MgmtInterface 85
Index 259
7901IX.fm Draft Document for Review April 13, 2011 6:45 am
Index 261
7901IX.fm Draft Document for Review April 13, 2011 6:45 am
WS-Addressing 228
WS-BaseNotification 228
WS-Management 228
advantages 228
disadvantages 228
WS-Proxy 131, 202
WS-ResourceProperites 228
WS-Topics 228
X
XML Gateway 202
XML Management Interface 220–222, 224
enabling 95
monitoring 79, 95
XML management interface 2
XMLFirewallService 80
xml-mgmt 5
xml-mgmt.wsdl 226
xml-mgmt.xsd 227
xml-mgmt-2004.wsdl 226
xml-mgmt-base.xsd 226
XPath 8
User Administration This IBM Redbooks publication is part of a two volume set
and Role-Based that focuses on operational and managerial aspects, as well INTERNATIONAL
Management as best practices for DataPower appliance deployments. TECHNICAL
SUPPORT
DataPower appliances provide functionality that crosses both
Network functional and organizational boundaries which introduces
ORGANIZATION
Configuration, unique management and operational challenges. For
Monitoring, and example, a DataPower appliance may provide network
Logging functionality such as load balancing while at the same time BUILDING TECHNICAL
providing ESB capabilities such as transformation and INFORMATION BASED ON
Appliance and intelligent content-based routing. PRACTICAL EXPERIENCE
Configuration This IBM Redbooks publication provides guidance at both a
Management general and technical level for individuals responsible for IBM Redbooks are developed by
planning, installation, development, and deployment. It is not the IBM International Technical
intended to be a “how-to” guide, rather to help educate Support Organization. Experts
about the various options and methodologies that apply to from IBM, Customers and
DataPower appliances. In addition, many chapters provide a Partners from around the world
create timely technical
list of best practices. information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
SG24-7901-00 ISBN