Clone the second node (sles102)
-------------------------------------------------------
1. After above configuration finished, shutdown the first node sles101, and copy all the vmware machine files to folder d:\sles102. Edit sles.vmx and make sure all shared disks are configured with the correct disk path.
2. power on the second node sles102 and update the NIC IP addresses.
During the boot, you will find the NICs eth0 and eth1on sles102 were renamed to eth2 and eth3. You need edit the "/etc/udev/rules.d/30_net_persistent_names.rules" file to change them back to device name eth0 and eth1.
sles102:/etc/udev/rules.d # cat 30-net_persistent_names.rules
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:6a:97:0d", IMPORT="/lib/udev/rename_netiface %k eth1"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:6a:97:03", IMPORT="/lib/udev/rename_netiface %k eth0"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:50:56:92:7f:09", IMPORT="/lib/udev/rename_netiface %k eth2"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:50:56:92:64:de", IMPORT="/lib/udev/rename_netiface %k eth3"
The NICs with MAC address "00:0c:29:6a:97:0d" and "00:0c:29:6a:97:03" are invalid here and no longer exist in this linux server, therefore, should be renamed with new MAC addresses that eth2 and eth3 are holding. The modified contents of rule file should looks like:
sles102:/etc/udev/rules.d # cat 30-net_persistent_names.rules
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:50:56:92:7f:09", IMPORT="/lib/udev/rename_netiface %k eth1"
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:50:56:92:64:de", IMPORT="/lib/udev/rename_netiface %k eth0"
Then, restart the udev and network service, you will get your eth0 and eth1 back.
--------------------------------------------------------------------------------------
Create user equivelence for user "root" and "oracle"
--------------------------------------------------------------------------------------
User equivalance should be configured for both "root" and "oracle" user, so that no password is required for authentication of copying/accessing between all RAC nodes.
Public keys (RSA and DSA) are required to be used with ssh login sessions. In this example, "ssh-keygen" will be used to generate the keys.
Creating User Equivalance Procedures are as below:
a. Generate public and private keys by "ssh-keygen" for user 'root', and copy all public keys to the "/root/.ssh/authorized_keys" on node1
b. Repeat above on node2
c. Merge the 2x authorized_keys contents on both nodes
d. Running "ssh" session for all public and private hostnames of both RAC nodes (generating the "known_hosts" file)
e. Repeat step a-d to generate authorized_keys file for user 'oracle'
a. On sles101, create RSA and DSA keys for user "root"
[root@sles101 .ssh]# ssh-keygen -b 1024 -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
33:2e:a1:20:09:6c:5d:d5:9f:1c:79:d4:09:b6:40:41
root@sles101.test.com
www.ixdba.net
[root@sles101 .ssh]# ssh-keygen -b 1024 -t rsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
33:2e:a1:20:09:6c:5d:d5:9f:1c:79:d4:09:b6:40:41 root@sles101.test.com
[root@sles101 .ssh]# ls -al
total 20
drwx------ 2 root root 4096 Oct 14 16:38 .
drwxr-x--- 14 root root 4096 Oct 14 10:55 ..
-rw------- 1 root root 668 Oct 14 16:38 id_dsa
-rw-r--r-- 1 root root 619 Oct 14 16:38 id_dsa.pub
-rw------- 1 root root 668 Oct 14 16:38 id_rsa
-rw-r--r-- 1 root root 619 Oct 14 16:38 id_rsa.pub
[root@sles101 .ssh]# cat id_dsa.pub >>authorized_keys
[root@sles101 .ssh]# cat id_rsa.pub >>authorized_keys
copy authorized_keys to "sles102"
[root@sles101 .ssh]# scp authorized_keys root@sles102:/root/.ssh/authorized_keys
The authenticity of host 'sles102 (172.16.2.146)' can't be established.
RSA key fingerprint is a8:ec:93:18:1c:e4:66:67:76:e0:73:ab:5e:90:e8:4b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'sles102,172.16.2.146' (RSA) to the list of known hosts.
root@sles102's password:
authorized_keys 100% 619 0.6KB/s 00:00
[root@sles101 .ssh]#
b. on sles102 , generate the DSA and RSA keys for "sles102" using same command lines.
c. Then merge the contents of "authorized_keys" and copied it to both nodes.
Now the "authorized_keys" file on both nodes contains the public keys for each other.
d. Running "ssh" session for all public and private hostnames of both RAC nodes (generating the "known_hosts" file)
[root@sles101 .ssh]# ssh sles101 date
[root@sles101 .ssh]# ssh sles102 date
[root@sles101 .ssh]# ssh sles101-priv date
[root@sles101 .ssh]# ssh sles102-priv date
[root@sles102 .ssh]# ssh sles101 date
[root@sles102 .ssh]# ssh sles102 date
[root@sles102 .ssh]# ssh sles101-priv date
[root@sles102 .ssh]# ssh sles102-priv date
e. Repeat step a-d to generate authorized_keys file for user 'oracle'
(Tips: running "ssh sles101 date" instead of "ssh sles101" so that it will not run into the ssh session)
Part2
- Installing CRS
- Configuring VIP (vipca)
-----------------------------------------------------------
Installing Oracle Clusterware (CRS)
-----------------------------------------------------------
1. copy the source zip file onto the source location or on an NFS share.
2. Before installing CRS (clusterware), it is better to run the prerequisites scrīpts:
[oracle@sles101 /mnt/oracle/clusterware/cluvfy]
$ ./runcluvfy.sh stage -pre crsinst -n sles101,sles102 -verbose
Performing pre-checks for cluster services setup
....
Checking node reachability...
Check: Node reachability from node "sles101"
Destination Node Reachable?
------------------------------------ ------------------------
sles101 yes
sles102 yes 
