Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Cluster Geographic Edition System Administration Guide Oracle Solaris Cluster 4.0 |
1. Introduction to Administering the Geographic Edition Software
3. Administering the Geographic Edition Infrastructure
4. Administering Access and Security
Geographic Edition Software and RBAC
Modifying a User's RBAC Properties
Configuring Secure Cluster Communication Using Security Certificates
5. Administering Cluster Partnerships
7. Administering Protection Groups
8. Monitoring and Validating the Geographic Edition Software
9. Customizing Switchover and Takeover Actions
A. Standard Geographic Edition Properties
B. Legal Names and Values of Geographic Edition Entities
C. Disaster Recovery Administration Example
E. Troubleshooting Geographic Edition Software
You can use IP Security Architecture (IPsec) to configure secure communication between partner clusters. IPsec enables you to set policies that permit or require either secure datagram authentication, or actual data encryption, or both, between machines communicating by using IP. Consider using IPsec for the following cluster communications:
Secure communication through The Availability Suite feature of Oracle Solaris, if you use the Availability Suite software for data replication
Secure TCP/UDP heartbeat communications
Oracle Solaris Cluster software and Geographic Edition software support IPsec by using only manual keys. Keys must be stored manually on the cluster nodes for each combination of server and client IP address. The keys must also be stored manually on each client.
Refer to the Part III, IP Security, in Oracle Solaris Administration: IP Services for a full description of IPsec configuration parameters.
In the Geographic Edition infrastructure, the hostname of a logical host is identical to the cluster name. The logical hostname is a special HA resource. You must set up a number of IP addresses for various Geographic Edition components, depending on your cluster configuration.
On each partner cluster, you must configure encryption and authorization for exchanging inbound and outbound packets from a physical node to the logical-hostname addresses. The values for the IPsec configuration parameters on these addresses must be consistent between partner clusters.
IPsec uses two configuration files:
IPsec policy file, /etc/inet/ipsecinit.conf. Contains directional rules to support an authenticated, encrypted heartbeat. The contents of this file are different on the two clusters of a partnership.
IPsec keys file, /etc/init/secret/ipseckeys. Contains keys files for specific authentication and encryption algorithms. The contents of this file are identical on both clusters of a partnership.
The following procedure configures a cluster, cluster-paris, for IPsec secure communication with another cluster, cluster-newyork. The procedure assumes that the local logical hostname on cluster-paris is lh-paris-1 and that the remote logical hostname is lh-newyork-1. Inbound messages are sent to lh-paris-1 and outbound messages are sent to lh-newyork-1.
Use the following procedure on each node of cluster-paris.
For a reminder of which node is phys-paris-1, see Example Geographic Edition Cluster Configuration.
The policy file is located at /etc/inet/ipsecinit.conf. Permissions on this file should be 644. For more information about this file, see the ipsecconf(1M) man page.
For information about the names and values that are supported by Geographic Edition software, see Appendix B, Legal Names and Values of Geographic Edition Entities.
The default port for the tcp_udp plug-in is 2084. You can specify this value in the etc/cacao/instances/default/modules/com.sun.cluster.geocontrol.xml file.
The following entry in the /etc/inet/ipsecinit.conf file configures a policy with no preference for authorization or encryption algorithms.
# {raddr lh-newyork-1 rport 2084} ipsec {auth_algs any encr_algs any \ sa shared} {laddr lh-paris-1 lport 2084} ipsec {auth_algs any encr_algs \ any sa shared}
When you configure the communication policy on the secondary cluster, cluster-newyork, you must reverse the policies.
# {laddr lh-newyork-1 lport 2084} ipsec {auth_algs any encr_algs \ any sa shared} {raddr lh-paris-1 rport 2084} ipsec {auth_algs any encr_algs \ any sa shared}
# ipsecconf -a /etc/inet/ipsecinit.conf
The communication file is located at /etc/init/secret/ipseckeys. Permissions on the file should be 600.
Add keys:
# ipseckey -f /etc/init/secret/ipseckeys
Key entries have the following general format:
# inbound to cluster-paris add esp spi paris-encr-spi dst lh-paris-1 encr_alg paris-encr-algorithm \ encrkey paris-encrkey-value add ah spi newyork-auth-spi dst lh-paris-1 auth_alg paris-auth-algorithm \ authkey paris-authkey-value # outbound to cluster-newyork add esp spi newyork-encr-spi dst lh-newyork-1 encr_alg newyork-encr-algorithm \ encrkey newyork-encrkey-value add ah spi newyork-auth-spi dst lh-newyork-1 auth_alg newyork-auth-algorithm \ authkey newyork-authkey-value
For more information about the communication files, see the ipsecconf(1M) man page.