Oracle RAC IP Detailed

Vip/public/private IP Differences in RAC environments

Each node to 2 network card, 3 IP, virtual IP or called the business IP, a single network card when it can "drift" to the other network card is to continue to provide services

In the Oracle RAC Environment, each node will have multiple IP addresses, respectively, PUBLIC/PRIVATE/VIP, what is the difference between these three IPs? What are the occasions for each? Take a look at the foreigner's answer.
1. Private IP address is used internal clustering processing (Cache Fusion)
Private IP for the heartbeat synchronization, this for the user level, can be directly ignored, simple understanding, this IP is used to ensure that the two servers synchronize data with the private network IP.
2. VIP is used by database applications to enable fail over when one cluster node fails
virtual IP is used for client applications to support failover, popular saying is one hangs, another automatic takeover, the client does not have any feeling.
This is one of the reasons why you should use RAC, another reason I think is load balancing.
3. Public IP adress are the normal IP address typically used by DBAs and SA to manage storage, system and database.
public IP is typically used by administrators to ensure that the right machine can be manipulated, and I prefer to call him a real IP.

through the above explanations, it is not difficult to understand that as a DBA, when configuring Tnsnames.ora, there are occasions when you want to use the VIP, and in some cases you must use the public IP. For example, when you are locating a deadlock in a database, using the public IP, you can ensure that you are connected to the machine you want to work on, instead of using the virtual IP at this time, there will be uncertainty, because the server by default is load balanced, that is, you may want to connect a machine, the system has assigned you a B machine.

here is reference:

/etc/hosts
#Publict NIC
10.104.4.31          test1.aaa.com                Test1
10.104.4.3 2          test2.aaa.com                TEST2
#Pr Ivate NIC
192.168.5.31         test1-pn.aaa.com                TEST1-PN
192.168.5.32         test2-pn.aaa.com                TEST2-PN
#oracle visal NIC for Oracle RAC VIP

10.104.4.35           test1-vip.aaa.com                 TEST1-VIP
10.104.4 .36          test2-vip.aaa.com                 TEST2 -vip 

For example:

The
following example is the use of the VIP

2. INFODB8 =
   
4. (DESCRIPTION =
   
6.      ADDRESS = ( Protocol= tcp = 138. * 1 Bayi Port
   
8.      ADDRESS = ( Protocol= tcp = 138. * 1 Port
   
10. (load_balance = Yes)
    
12. (FAILOVER = on)
    
14. (connect_data =
    
16. (SERVER= dedicated)
    
18. (service_name = infodb)
    
20. (failover_mode =
    
22. (TYPE=SELECT)
    
24. (METHOD= BASIC)
    
26. (retries = +)
    
28. (DELAY = 5)
    
30. )
    
32. ))

2. The following example is the use of the public IP, specify the connection 1 machine, note the red font INFODB1 further limit the connection instance.
   
4. INFODB83 =
   
6. (DESCRIPTION =
   
8. (address_list =
   
10. (ADDRESS= (PROTOCOL= TCP)(HOST=138 . * . 1. (PORT= 1521))
    
12. )
    
14. (connect_data =
    
16. (service_name = infodb)
    
18. (instance_name = infodb1)
    
20. )
    
22. (HS = OK)
    
24. )
25. Oracle 11gR2 SCAN detailed--alan.lee Original, reproduced please indicate the sourcewww.dbaleading.com

    Prior to Oracle 11GR2, if the database had a RAC schema, in the client's tnsnames, the connection information for multiple nodes needed to be configured to implement features such as load balancing, failover, and so on. Therefore, when a database RAC cluster needs to add or remove nodes, it is necessary to update TNS on the client machine in a timely manner to avoid any security risks.

    In 11gr2, in order to simplify this configuration, the feature of the scan (single client Access Name) was introduced, the benefit of which is the addition of a layer of virtual service layer between the database and the client, the so-called scan IP and the scan IP Listener, the client only needs to configure the TNS information of the scan IP, through the scan IP listener, connect the background cluster database. This will not affect the client regardless of whether the cluster database has operations to add or remove nodes.

    The following is a detailed description of the schema and configuration of the following scan (single Client Access Name).

    First of all, a brief look at the great changes in the installation of RAC in the 11GR2, in the 10g and 11gr1 era, the installation of RAC is first installed CRS, then installed DB, and in the 11gr2 era, CRS and ASM are integrated together, collectively referred to as grid, must first install the grid after , you can continue to install the DB, otherwise, you will not be with 11GR2 RAC, hehe.
    The scan that was introduced by 11GR2 is included in the process of installing the grid. Scan definition, there are two ways:
    1. Define the domain name in DNS.
    2. Implement DHCP customizations with the grid naming Server (GNS) provided by Oracle.
    If you define through DNS, you need to define 3 scan IP addresses in the network, point to the same domain name, the 3 IP addresses must be in the same subnet, and the domain name can not be too long, otherwise you typing trouble is not, haha. In addition, the SCAN IP is managed by Oracle Clusterware, so this IP cannot be configured in the host's cluster software (such as IBM HACMP,HP SERVICE GUARD), similar to the VIP in 10g, before the grid is installed, This IP is not ping-pass.
    Example:
    Scan-ip.dbaleading.com in A 192.168.1.111
    In A 192.168.1.112
    In A 192.168.1.113
    If you use GNS, you must have a DHCP service, and during the configuration of cluster, you will automatically request 3 IP addresses from the DHCP server for use as a scan IP.

    In addition to the scan IP, during the configuration of the cluster, the scan IP LISTENER service will also be established, each scan IP corresponding to a scan IP LISTENER, and, in order to raise the availability, 3 scan IP and its corresponding scan IP The listener will be independently assigned to each node. If an exception occurs for one of the nodes running the scan IP in cluster, the remaining two normal scan IP nodes are automatically taken over. Note that there is a note here, if the client is 11GR2 version, then the client only need to configure the domain name resolution in TNS, can implement failover, if the client version is less than 11GR2, you can not resolve the domain name 3 scan IP address, so if you want to implement failover, The address of the 3 scan IP must be configured in TNS in the client, which is why Oracle strongly recommends that clients use 11GR2 when using the 11GR2 database.
    Example:
    $srvctl Config Scan_listener
    SCAN Listener Listener_scan1 exists. port:tcp:1521
    SCAN Listener listener_scan2 exists. port:tcp:1521
    SCAN Listener LISTENER_SCAN3 exists. port:tcp:1521
    $srvctl Config Scan
    SCAN Name:scan-ip, network:1/192.168.1.0/255.255.255.0/
    SCAN VIP name:scan1, IP:/scan-ip.dbaleading.com/192.168.1.111
    SCAN VIP name:scan2, IP:/scan-ip.dbaleading.com/192.168.1.112
    SCAN VIP name:scan3, IP:/scan-ip.dbaleading.com/192.168.1.113
    

       
        Read the first article in the scan IP introduction, I believe many friends have such a question, since the scan IP is not related to the database instance, For example, a 12-node RAC or 24-node RAC with only 3 scan IPs, and the scan IP is randomly distributed across the instance, how does the scan IP listener listen to the database of each node, How to configure which instance to go to which scan IP listener register it. Here are answers.
       
        First, add a concept, in 11gr2, SCAN IP as a new IP appears, the original CRS in the VIP still exist, from here, can see a little clue, In the 11GR2 RAC architecture, SCAN IP does not exist independently, but is combined with the original VIP. So how do they work, first look at the following work schematic:
       

    From this schematic, it can be seen that the scan IP is in fact the Ora CLE between the client and the database, a new connection layer, when there is a client access, connected to the scan IP LISTENER, and the scan IP LISTENER received the connection request, according to the LBA algorithm (so-called L BA algorithm, is least loaded instance), the client's connection request, forwarded to the corresponding instance VIP LISTENER, thus completing the entire client-server connection process. Simplify as follows:
    Client, scan listener, local listener, local instance

    Knowing the process, the overall architecture of the scan IP is clear. For the rest, let's talk about some technical details.
    Scan IP and Scan LISTENER are independent of each node of the RAC, and each node VIP, VIP LISTENER is bound with instance, each node VIP LISTENER, will listen to their own node instance.

    Therefore, in the database, we need to set the Remote_listener parameter, this parameter setting is very fastidious, because the scan IP has 3, scan listener also has three, but they correspond to the same domain name, therefore, in the database, we need to use the easy The Connect naming method means that there must be names.directory_path= (Tnsnames,ezconnect) in the Sqlnet.ora configuration file.

    In addition, the way to configure Remote_listener is also fastidious, in the previous version, we usually write a good remote_listener address and port in Tnsnames.ora, but for scan listener, cannot do so, must follow the standard format , set to Remote_listener=scan:port form, take my test system as an example, is remote_listener=scan-ip.dbaleading.com:1521, without the need for additional settings in Tnsnames.ora.

    after the above settings, each node of the RAC database Pmon process will be broadcast to each scan listener registration, while the CRS background process ONS, will collect the load status of each node, notify scan listener, so that scan Listener the new connection is assigned to the node with the lowest current load, depending on the load situation.
    
    The above is the entire contents of the new scan IP and Scan listener in the 11GR2 RAC, and in the following chapter we will carry out some extensibility considerations and discussions on this new feature.
27. Appendix:
31. In fact, in the RAC environment, the NIC is working in promiscuous mode, like Tcpdump, which will bring in all the packets sent to the address.
35. Two NICs per node, one set public IP, one set private IP
    In the Hosts file to put two nodes a total of 6 IP must be written in
39. VIP is not tied, Oracle installation itself will be tied, only need to bind public and private can
43. Create an Oracle RAC teng R2 using VMware Workstation 5
45. Http://www.idevelopment.info/data/Oracle/DBA_tips/VMware_Workstation_50/VMWARE_31.shtml