B.1 Assigning Services to Nodes

The following steps are necessary to configure the services that run on the cluster nodes.

  1. Configure the database server for each node:

    1. Change the db_host variable assignment to specify the database host.

    2. For new installations, do not change db_name, db_user and db_pswd.

    3. Define the host access to the database.

      The servers that run the address book, XML routers, and Web portals must have access to the database. You can specify access to the database host using a set of IP addresses and netmasks. An IP address/netmask pair specifies a range of IP addresses that are allowed to connect to the database. For instance, 10.1.1.1/255.255.255.0 allows IP addresses 10.1.1.* to connect to the database. The IP addresses are specified in db_ip_addr and the netmasks in db_netmask. Both are arrays, so the above example would be:

      db_ip_addr=( 10.1.1.1 )

      db_netmask=( 255.255.255.0 )

  2. Configure XML router services:

    1. Set external_hname to the hostname used by Conferencing clients to connect to XML router services.

    2. Set the lcl_xmlrouter and lcl_xmlrouter_ip arrays to specify the cluster hosts and IP addresses for the XML router services. More than two XML routers are not currently supported.

  3. Configure services connected to the XML router:

    1. Configure the meeting controller service and the backup meeting controller service if necessary. Specify the cluster hosts to run each and the XML router listen ports. The hosts are specified in the controller_host array and the listen ports in the controller_port array.

    2. Configure the addressbk service. Specify the cluster host and XML router listen ports by setting the addressbk_host array and the addressbk_port array. Currently, only one addressbk is supported.

    3. Configure the mailer service. Specify the cluster host and XML router listen ports by setting the mailer_host array and the mailer_port array. Currently, only one mailer is supported.

    4. Configure the voice bridges. Multiple voice bridges can be configured for scaling purposes (see Section C.0, Editing the dialing.xml File):

      1. Specify the cluster hosts and XML router listen ports by setting thevoice_host array and the voice_port array.

      2. Specify the voice provider for the voice bridges using the voice_provider variable. If no voice support has been purchased, use the value stub. If an NMS voice bridge has been purchased, use the value nms.

      3. Specify the phone numbers allocated to each bridge by using the voice_phones array. You can assign multiple phone numbers to a single voice bridge by separating the phone numbers with commas. Note that if spaces appear in phone numbers, the phone numbers must be quoted. Also, if the stub voice provider is in use, a dummy voice bridge number must be specified (such as “999-555-1234”).

    5. Configure the meeting archiver services. You can configure multiple meeting archivers for scaling purposes:

      1. Specify the assigned cluster hosts and XML router listen ports by setting the mtgarchiver_host array and the mtgarchiver_port array.

      2. If the meeting archiver hosts are separated from a voice bridge host by a NAT router, use the mtgarchiver_voice_host array to specify the voice bridge hosts from the meeting archivers’ perspective. If no NAT router is involved, the meeting archivers attempt to connect to the voice bridges using the hostnames found in voice_host.

    6. Configure the external API service by specifying the cluster host and XML router listen ports to set the extapi_host and extapi_port arrays. You can use multiple external API hosts.

  4. Configure the app/desktop sharing servers:

    1. Configure the share_host array to specify which hosts run as app/desktop sharing servers.

      You can run multiple app/desktop servers on a single host by specifying a host multiple times. For instance if share_host was assigned the value kanga kanga roo, the host named kanga would run two servers and roo would run one. Also, be aware that you would need to define two distinct IP addresses on kanga, because both servers use port 80 for tunneling through firewalls.

    2. Configure the port to use for each share server using the share_port array.

      This port can remain as 2182, because the IP addresses must be distinct for each share server. Port 2182 does not conflict with any default Linux service.