修改RAC 地址

kidking2010發表於2015-05-15

轉自:http://blog.itpub.net/15480802/viewspace-742160/

RAC節點常用到的IP包括public IP, VIP和private IP, 11R2開始還多出了一個SCAN VIP,這些IP資訊都應該在安裝階段配置,但是可能在後續維護過程中需要修改相應的資訊。

下面就分別介紹一下修改各類IP資訊的大致步驟

 

修改Public network資訊

 

Case I.   修改public hostname

--除非是重灌clusterware或重新新增該node,否則無法更改

Public hostname is recorded in OCR, it is entered during installation phase. It cannot be modified after the installation. The only way to modify public hostname is by deleting the node, then add the node back with a new hostname, or reinstall the clusterware.

 

Case II.  修改public IP,但不改動子網資訊

--更改public IP,不修改子網資訊,只需要更改OS配置,但需要重啟clusterware

If the change is only public IP address and the new ones are still in the same subnet, nothing needs to be done on clusterware layer, all changes need to be done at OS layer to reflect the change.

1. Shutdown Oracle Clustereware stack

2. Modify the IP address at network layer, DNS and /etc/hosts file to reflect the change

3. Restart Oracle Clusterware stack

 

Case III.修改public IP,更改子網資訊

--需要修改OCR,需要重啟clusterware

If the change involves different subnet(netmask) or interface, delete the existing interface information from OCR and add it back with the correct information is required.  In the example here, the subnet is changed from 10.2.156.0  to 10.2.166.0 via two separate commands - first a 'delif'  followed by a 'setif':

 

For example:

% $CRS_HOME/bin/oifcfg delif -global eth0/10.2.156.0

% $CRS_HOME/bin/oifcfg setif -global eth0/10.2.166.0:public

Make the change at OS layer and restart Oracle Clusterware.

 

Once public network is changed, its associated VIP and SCAN VIP are also required to change, refer to CASE IV and CASE V.

 --當public 網段改變的時候,其相應的VIP和SCAN VIP也需要做出相應的改變

 

 

修改VIP資訊

--修改VIP,10203以後ASM/DB instance不再依賴VIP,因此修改VIP時無需將其關閉,但此過程中該節點將無法被客戶端訪問;

--11R2若使用GNS,則VIP無需手工配置

--先停止現有的VIP,修改OS配置,以root使用者執行srvctl修改其VIP資訊,重啟該服務既可

 

Planning for VIP changes

In general, a complete outage is only required for pre-10.2.0.3 release. From 10.2.0.3 onwards, the ASM/database instance dependency on the VIP resource is removed, so the VIP could be modified without having to take down the ASM/database instance, only client connections to the database will be affected when VIP is down. If the modification is a node specific, then only connection to that node will be affected during the time of change.

 

Please follow Case III to ensure public network changes are made first.

 

Gathering Current VIP Configuration

1. Gather the existing setup

for 10g and 11gR1, as Oracle Clusterware owner:

$ srvctl config nodeapps -n racnode1 -a

VIP exists.: /racnode1-vip/101.17.80.184/255.255.254.0/eth1

 

for 11gR2, as Grid Infrastructure owner:

$ srvctl config nodeapps -a

Network exists: 1/101.17.80.0/255.255.254.0/eth1, type static

VIP exists: /racnode1-vip/101.17.80.184/101.17.80.0/255.255.254.0/eth1, hosting node racnode1

VIP exists: /racnode2-vip/101.17.80.186/101.17.80.0/255.255.254.0/eth1, hosting node racnode2

 

2. Verify VIP status

 

10.2 and 11.1:

$ crs_stat -t

 

11.2:

$ crsctl stat res -t

- it should show VIPs are ONLINE

 

$ ifconfig -a

(netstat -in for HP and ipconfig /all for Windows)

- VIP logical interface is bound to the public network interface

 

 

Stopping Resources

3. Stop the nodeapps resources (and all dependent resources ASM/DB only if required):

 

10g and 11gR1, as Oracle Clusterware owner:

 

$ srvctl stop instance -d -i    (optional for 10.2.0.3+)

$ srvctl stop asm -n                      (optional for 10.2.0.3+)

$ srvctl stop nodeapps -n

 

11gR2, as Grid Infrastructure owner:

 

$ srvctl stop instance -d -n     (optional)

$ srvctl stop vip -n -f

 

 

Note 1: The -f option is required for 11gR2 to stop listener resource, otherwise following error will occur:

PRCR-1014 : Failed to stop resource ora.racnode1.vip

PRCR-1065 : Failed to stop resource ora.racnode1.vip

CRS-2529: Unable to act on 'ora.racnode1.vip' because that would require stopping or relocating 'ora.LISTENER.lsnr', but the force option was not specified

...

 

4. Verify VIP is now OFFLINE and the interface is no longer bound to the public network interface

 

$ crs_stat -t (or $ crsctl stat res -t for 11gR2)

 

$ ifconfig -a

(netstat -in for HP and ipconfig /all for windows)

 

 

Modifying VIP and Its Associated Attributes

5. Determine the new VIP IP/subnet/netmask or VIP hostname, make the network change on OS first, ensure the new VIP is registered in DNS or modified in /etc/hosts (for Unix/Linux) and \WINDOWS\System32\drivers\etc\hosts file (for Windows). If the network interface is changed, ensure the new interface is available on the server before proceeding with the modification.

 

For example:

New VIP is: 110.11.70.11 racnode1-nvip

new subnet is 110.11.70.0

new netmask is 255.255.255.0

new interface is eth2

 

6. Modify the VIP resource, as root user:

 

# srvctl modify nodeapps -n -A //

 

eg:

# srvctl modify nodeapps -n racnode1 -A racnode1-nvip/255.255.255.0/eth2

 

* A special case for 11gR2 modifying the VIP hostname only without changing the IP address.

 

For example: only VIP hostname changes from racnode1-vip to racnode1-nvip, IP and other attributes remain same.

 

If IP address is not changed, above modify command will not change the USR_ORA_VIP value in 'crsctl stat res ora.racnode1.vip -p' output. To workaround:

 

1. modify VIP to use another valid hostname, for example node2 VIP host:

# srvctl modify nodeapps -n racnode1 -A racnode2-vip/255.255.255.0/eth2

 

2. modify VIP again to use the new VIP hostname

# srvctl modify nodeapps -n racnode1 -A racnode1-nvip/255.255.255.0/eth2

 

3. Verify the changes for USR_ORA_VIP field:

# crsctl stat res ora.racnode1.vip -p

 

 

Note 1: For Windows platform, the interface name needs to be in quote (") if there is a space in between, eg:

As administrator user or software install user:

> srvctl modify nodeapps -n racnode1 -A 110.11.70.11/255.255.255.0/"Local Area Connection 1"

 

Note 2: Starting with 11.2, the VIP depends on network resource (ora.net1.network), the OCR only records the VIP hostname or the IP address associated with the VIP resource. The network attributes (subnet/netmask) is recorded with the network resource.

 

From 11.2.0.2 onwards, if only subnet/netmask change is required, network resource can be modified directly via srvctl modify network command.

 

as root user:

# srvctl modify network -k ] [-S /[/if1[|if2...]]

 

eg:

# srvctl modify network -k 1 -S 110.11.70.0/255.255.255.0/eth2

 

There is no need to modify VIP or SCAN if other attributes are not changed.

 

7. Verify the change

 

$ srvctl config nodeapps -n -a (10g and 11gR1)

$ srvctl config nodeapps -a (11gR2)

 

eg:

$ srvctl config nodeapps -n racnode1 -a

VIP exists.: /racnode1-nvip/110.11.70.11/255.255.255.0/eth2

 

 

Restarting Resources

8. Start the nodeapps and the other resources

 

10g and 11gR1, as Oracle Clusterware owner:

 

$ srvctl start nodeapps -n       

$ srvctl start asm -n                (optional for 10.2.0.3+)

$ srvctl start instance -d -i    (optional for 10.2.0.3+)

 

eg:

$ srvctl start nodeapps -n racnode1

$ srvctl start asm -n racnode1

$ srvctl start instance -d RACDB -i RACDB1

11gR2, as Grid Infrastructure owner:

 

$ srvctl start vip -n

$ srvctl start instance -d -n       (optional)

 

eg,

$ srvctl start vip -n racnode1

$ srvctl start instance -d RACDB -n racnode1

 

9. Verify the new VIP is ONLINE and bind to the public network interface

 

$ crs_stat -t (or $ crsctl stat res -t for 11gR2)

 

$ ifconfig -a

(netstat -in for HP or ipconfig /all for windows)

 

10. Repeat the same steps for the rest nodes in the cluster only if the similar change is required.

 

Others

11. Modify listener.ora,  tnsnames.ora and LOCAL_LISTENER/REMOTE_LISTENER parameter to reflect the VIP change if necessary.

 

修改SCAN VIP

Case V. Change SCAN VIP associated with public network change

--修改SCAN VIP(僅限於不使用GNS的場景)

--首先需要修改DNS配置,然後停止scan服務並同步其OCR配置

--原有的SCAN IP地址10.100.10.81, 10.100.10.82 & 10.100.10.83,修改後的SCAN IP為10.100.10.121, 10.100.10.122 & 10.100.10.123

1

確認DNS的scan ip已經修改

$ nslookup sales-scan.example.com

Server:         dns1.example.com

Address:        10.100.10.70#53

 

Name:   sales-scan.example.com

Address: 10.100.10.123

Name:   sales-scan.example.com

Address: 10.100.10.122

Name:   sales-scan.example.com

Address: 10.100.10.121

2

停止scan和scan listener服務

# $GRID_HOME/bin/srvctl stop scan_listener

# $GRID_HOME/bin/srvctl stop scan

# $GRID_HOME/bin/srvctl status scan

# $GRID_HOME/bin/srvctl status scan_listener

3

修改OCR配置

# $GRID_HOME/bin/srvctl modify scan -n sales-scan.example.com

4

重啟scan和scan listener

# $GRID_HOME/bin/srvctl start scan

# $GRID_HOME/bin/srvctl start scan_listener

 

Before the SCAN VIPs can be changed, the entry for the SCAN name on the Domain Name Server (DNS) needs to be updated with the new IP addresses. This usually will be done by a network administrator. To check the current setting, the following command can be used:

nslookup

 

To check the current IP address(es) of the SCAN VIPs, run the following commands as the root user: $GRID_HOME/bin/srvctl config scan

 

Next refresh the SCAN VIPs with the new IP addresses from the DNS entry: $GRID_HOME/bin/srvctl modify scan -n

 

To check if the SCAN VIPs have been changed, run the following command, it should now show the new IP addresses.$GRID_HOME/bin/srvctl config scan

With Grid Infrastructure 11gR2, SCAN and SCAN VIP are introduced for client connections. To modify the SCAN VIP, please refer to

 

Note 952903.1 How to update the IP address of the SCAN VIP resources (ora.scan.vip)

Note 972500.1 How to Modify SCAN Setting or SCAN Listener Port after Installation

 

修改private IP

--

Case I. Changing private hostname

--11R2起 private hostname不再儲存於OCR中,可以在/etc/hosts隨意修改;此前的版本private hostname一旦確定便不可修改,除非重灌clusterware

In pre-11.2 Oracle Clusterware, private hostname is recorded in OCR, it can not be updated. Generally private hostname is not required to change. Its associated IP can be changed. The only way to change private hostname is by deleting/adding nodes, or reinstall Oracle Clusterware.

 

In 11.2 Grid Infrastructure, private hostname is no longer recorded in OCR and there is no dependancy on the private hostname. It can be changed freely in /etc/hosts.

 

 

Case II. 只修改private IP

--關閉clusterware,然後再修改OS配置檔案/etc/hosts

For example, private IP is changed from 192.168.1.10 to 192.168.1.21, network interface name and subnet remain the same.

 

Simply shutdown Oracle Clusterware stack, make IP modification at OS layer (eg: /etc/hosts, OS network config etc) for private network, restart Oracle Clusterware stack will complete the task.

 

 

Case III. 修改private IP及其子網資訊

--不僅修改/etc/hosts,還要修改OCR配置檔案

When netmask is changed, the associated subnet ID is also changed. Oracle only store network interface name and subnet ID in OCR, not the netmask. Oifcfg command can be used for such change, oifcfg commands only require to run on 1 of the cluster node, not all.

Pre11R2

1 呼叫oifcfg增加新的private network資訊,然後刪除舊的資訊

% $ORA_CRS_HOME/bin/oifcfg setif -global eth3/192.168.2.0:cluster_interconnect

% $ORA_CRS_HOME/bin/oifcfg delif -global eth1/192.168.1.0

2 關閉clusterware

以root使用者執行crsctl stop crs

3 更改OS層面的配置檔案

修改/etc/hosts,需要修改每個節點

4 重啟clusterware

11R2

--11.2的Grid框架中,private network配置資訊還存在於GPnP中,但無法手工直接修改該檔案,在修改之前需要備份一下profile.xml

以下操作都需要以grid使用者執行

1

確認所有節點的叢集都在執行

2

新增新的cluster_interconnect資訊

$ oifcfg setif -global eth3/192.168.1.96:cluster_interconnect

--使用-node選項會導致節點被驅逐

3

關閉所有節點的clusterware

4

修改OS層面的網路配置

5

重啟所有節點的clusterware

6

刪除舊的cluster_interconnect資訊

$ oifcfg delif -global eth0/192.168.0.0

 

參考文件

How to Modify Public Network Information including VIP in Oracle Clusterware [ID 276434.1]

How to Modify Private Network Information in Oracle Clusterware [ID 283684.1]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23141985/viewspace-1656647/,如需轉載,請註明出處,否則將追究法律責任。

相關文章