 |
|
Search for in all of Sybase.com |
view all search results  |
|
|
Release BulletinDocument ID: DC76342-01-1500-011. Accessing current release bulletin informationA more recent version of this release bulletin may be available on the Web. To check for critical product or document information added after the release of the product CD, use the Sybase® Technical Library Product Manuals Web site. Accessing release bulletins at the Technical Library Product Manuals Web site
2. Product summaryEnclosed is Sybase OpenSwitch 15.0, which is compatible with the following platform and operating system configurations:
3. Changed functionalityThis section describes new and changed functionality in OpenSwitch 15.0. Each functionality description also contains a reference to more information in the OpenSwitch documentation. 3.1 New featuresThis section describes new functionality in OpenSwitch version 15.0. 3.1.1 New standalone configuration toolOpenSwitch 15.0 includes an easy to use configuration tool with a graphical user interface (GUI). You access the configuration tool directly from the OpenSwitch installation program, or by starting the tool as a standalone application after installation. See the OpenSwitch installation guide for your platform, Chapter 2, “Configuring OpenSwitch,” for specific details. 3.1.2 New mutually-aware OpenSwitch server supportOpenSwitch version 15.0 supports a redundant “mutually-aware” environment with two OpenSwitch servers that serve the same pools of two Adaptive Server® Enterprise servers. Each OpenSwitch server is aware of the other OpenSwitch server and whether the connections and Adaptive Servers for which that server is responsible are up or down. See Chapter 5, “Using Mutually-Aware OpenSwitch Servers,” in the OpenSwitch Administration Guide. 3.1.3 New general registered proceduresSeveral new general registered procedures have been added to OpenSwitch version 15.0. See Chapter 6, “Registered Procedures,” in the OpenSwitch Administration Guide. 3.1.4 New coordination module registered proceduresSeveral new coordination module (CM) registered procedures have been added to OpenSwitch version 15.0. See Chapter 3, “Coordination Module Routines and Registered Procedures,” in the OpenSwitch Coordination Module Reference Guide. 3.1.5 New coordination module APIOpenSwitch 15.0 includes the new coordination module API cm_get_value, which is used to retrieve the mutually-aware configuration value of an OpenSwitch server. See Chapter 3, “Coordination Module Routines and Registered Procedures,” in the OpenSwitch Coordination Module Reference Guide and Chapter 5, “Using Mutually-Aware OpenSwitch Servers,” in the OpenSwitch Administration Guide for information about mutually-aware support. 3.1.6 Using concurrent coordination modulesOpenSwitch 15.0 allows you to run multiple coordination modules (CMs) concurrently against one OpenSwitch server to create a redundant environment where CM is not a single point of failure. See Chapter 2, “Using Coordination Modules,” in the OpenSwitch Coordination Module Reference Manual. 3.1.7 Starting and stopping the Replication Coordination Module from OpenSwitchVersion 15.0 allows you to start and stop the Replication Coordination Module (RCM) directly from OpenSwitch, which results in these additions to the product:
See Chapter 3, “Starting and Stopping OpenSwitch and RCMs,” in the OpenSwitch Administration Guide, and Chapter 4, “Using the Replication Coordination Module,” in the OpenSwitch Coordination Module Reference Manual. 3.2 Updated functionalityThis section describes the updated functionality for OpenSwitch 15.0. 3.2.1 IP version 6 supportOpenSwitch version 15.0 supports the IPv6 ìnext generationî protocol designed by the IETF to replace the current version Internet Protocol, IP Version 4 (ìIPv4î). IPv6 support is available on: IPv6 addresses a number of problems with IPv4, such as the limited number of available IPv4 addresses, which are needed by all new machines added to the Internet. IPv6 increases address size from 32 bits to 128 bits. It also adds many improvements to IPv4 in areas, such as routing and network auto-configuration. IPv6 is expected to gradually replace IPv4, with the two coexisting for a for a number of years during the transition period. 3.2.2 Registered proceduresThe following registered procedures have changed in OpenSwitch 15.0:
3.2.3 Connect client application deployment updateThe OpenSwitch configuration file has a new parameter called USE_DONEINPROCS, which resolves the problem of OpenSwitch not relaying the TDS token DONEPROC and DONEINPROC from Adaptive Server Enterprise to the client. See “Deployment issues” in Chapter 1, “Overview,” in the OpenSwitch Administration Guide. 3.2.4 Additional rp_debug flagThe following debug flags have been added to rp_debug as part of this release, including:
See Chapter 6, “Registered Procedures,” in the OpenSwitch Administration Guide for more information. 3.2.5 MAX_LOG_MSG_SIZEThe value of the OpenSwitch configuration parameter MAX_LOG_MSG_SIZE has changed to 2048. See Chapter 4, “Using the Configuration File,” in the OpenSwitch Administration Guide. 3.2.6 Connection Monitor on startupIf the Connection Monitor (CMON) configuration option is set to 1, OpenSwitch starts a CMON connection to an Adaptive Server when it receives its first client connection request. The client connection is not made until the CMON connection is successfully started. 3.3 Known limitations of mutually-aware OpenSwitchThis section describes some known limitations with the new mutually-aware OpenSwitch feature. 3.3.1 MAS does not propagate some functionsMutually-aware OpenSwitch does not propagate the following functions to its companion: If you issue any of these commands on one of the companions, manually repeat the commands on the other companion. In addition, check that your Coordination Module applications do not contain the equivalent of these commands. If they do, you must find a way to notify the administrator when the commands are called by the Coordination Module, so that the administrator can manually repeat the same commands on the other companion OpenSwitch. 3.3.2 OpenSwitch does not run user scripts when you use CM or RCMIf you are using a Coordination Module or a Replicated Coordination Module, OpenSwitch does not run any user scripts during a client failover, even if you define SVR_FAIL_ACTION as CUSTOM or MANUAL. 3.3.3 Some user errors cannot be preventedCurrently there is no way to prevent certain user errors, for example, if users started two companions in a mutually-aware cluster, one with MUTUAL_AWARE set to 1, and the other set to 0. Such a setup can lead to the two companions not communicating with each other, thereby forsaking the whole purpose of mutually-aware OpenSwitch to maintain constant configuration information across two OpenSwitch servers. You also see a user error when both mutually-aware companions are started with the -O option, which can lead to the two OpenSwitch companions being unsynchronized in their configurations. This opens up room for data loss during an Adaptive Server failure. 4. Known problemsThis section describes known problems in OpenSwitch version 15.0. 4.1 Pools are not suspended in a companion server failure scenario in mutually-aware environments[CR #415689] UNIX only – If you set both of the following, OpenSwitch does not execute custom or manual scripts during a network outage between the companions: Instead, you see an OpenSwitch message such as the following, informing you that it could not suspend the pools and execute the scripts: posw: INFO: spid 8: manual_action: Executing /usr/u/uagrawal/manual.sh (server=sosw, reason=1006) posw: ERROR: spid 8: pool_set_prop_atomic: Failed to preset pool status in companion. posw: ERROR: spid 8: coord_suspend: Cannot change status of pool POOL1 to SUSPENDED posw: ERROR: spid 8: manual_action: Suspending OpenSwitch failed. posw: ERROR: spid 8: do__useraction: Failed to execute the manual script for CMP_FAIL_ACTION. Check the error messages above for reasons of failure. posw: DEBUG: spid 8: All future changes to the server/pool configuration are prohibited. Workaround: Set CMP_FAIL_ACTION to DEFAULT. If you do not want the configuration to freeze during a network outage between the companions, set FREEZE_CFG_ON_FAIL to 0. Otherwise, set FREEZE_CFG_ON_FAIL to 1. 4.2 New clients take time to connect after primary Adaptive Server networks fail in mutually-aware environments[CR 415556] When the network between OpenSwitch and the primary Adaptive Server breaks, the first client that tries to connect to the primary Adaptive Server through OpenSwitch can take several minutes to detect the failure, even if the PING_THREAD is set to 1. After the first client detects the failure, it marks the server as down, and all subsequent clients from that point on failover to the secondary Adaptive Server upon connecting. Workaround: You must set the client timeout to a value greater than the TCP/IP timeout value (for example, tcp_ip_abort_interval on Solaris) so that the first client can correctly detect the TCP/IP timeout and set the server status appropriately for future clients. 4.3 Companion OpenSwitches are out of sync once network is restored[CR #414785] Windows only – if you return with an exit status of 1 from NET_FAIL_ACTION CUSTOM or MANUAL scripts, after the network is successfully restored, any changes you make to the pool/server might not get synced with its companion. Workaround: Always return an exit status of 0 from the CUSTOM or MANUAL scripts for NET_FAIL_ACTION. 4.4 Manual script not executed when a new client connection established in mutually-aware environments[CR #414784] This problem occurs if you set SVR_FAIL_ACTION in a mutually-aware environment to MANUAL, CUSTOM, or CUSTOM_MANUAL. If all existing clients on OpenSwitch are idle when a server fails, and a new client attempts to connect after the server has failed but before the existing (idle) clients become busy again, that new client gets connected to the secondary data server, and the existing clients hang. Workaround: This problem does not occur if you set SVR_FAIL_ACTION to DEFAULT. However if you set SVR_FAIL_ACTION to CUSTOM, MANUAL, or CUSTOM_MANUAL, make sure you have at least one busy client connected to the OpenSwitch at all times. If you cannot ensure this, you can write the following SQL script to create a busy client that runs in the background:
Use a name for this script that is easy to remember, such as busy.sql, and run this script through isql in the background as a regular user to OpenSwitch:
You should run this on both OpenSwitch companions, so that busy.sql can detect a server failure immediately, allowing you to handle the failure appropriately. 4.5 Replication switch occurs more than once during failover[CR #414693] The Replication Coordination Model attempts to perform the replication switch more than once when a failover situation occurs. The subsequent switch attempts will fail and have no impact on client applications. Workaround: There is no workaround, as this does not impact the RCM or Openswitch. 4.6 Applications using pre TDS 4.6 protocol may not work with OpenSwitch 15.0[CR #414518] An Open Server™ regression from CR #382803, this issue only affects applications using pre-Tabular Data Stream 4.6 clients. For clients using TDS versions earlier than 4.6, Open Server does not run the packetsize negotiation properly, thus preventing such clients from connecting to OpenSwitch version 15.0. Workaround: There is no workaround for this problem. 4.7 OpenSwitch configuration options with NULL values report errors when issuing rp_set[CR 414398] You see an error message that starts with, “Unable to get value of option...” when you issue an rp_set command with its <option> configured with a NULL value in the OpenSwitch configuration file:
Workaround: Modify the configuration options to have a valid non-NULL value in your OpenSwitch configuration file. 4.8 Starting mutually-aware OpenSwitch cluster with -O command[CR 399350] If both companions in a mutually-aware OpenSwitch cluster are started with the -O command, they both run as the Primary Companion, and the companion that started first runs in a single-server mode. Workaround: Do not use the -O command to start an OpenSwitch in a mutually-aware cluster that already has another OpenSwitch running. 5. Product compatibilitiesOpenSwitch 15.0 is compatible with:
The RCM 15.0 is compatible with:
6. Documentation updates and clarificationsThis section discusses documentation updates and clarifications. 6.1 OpenSwitch Reference ManualThe following discusses updates and clarifications for the OpenSwitch Coordination Module Reference Manual. 6.1.1 Sample cml.c fileThe cm1.c sample has been modified such that, when a primary server is detected to be down, cm1 not only marks it as down, but also removes it from the pool. When the primary server comes back up, cm1 marks it as up and adds it to the end of the pool. This way, new clients can continue to be redirected to the secondary server until the administrator deems it appropriate to switch back all the connections by manually executing the failback sequence as described below:
The above change does not apply to mutually-aware setups. If MUTUALLY_AWARE is set to 1, cm1 only marks the primary server as down when it detects a failure, but does not remove the server from the pool. Likewise, when the server comes back up in a mutually aware setup, cm1 marks the server as up, and the primary server begins accepting connections right away. If this behavior is undesirable, the administrator can modify the cm_time_ping() function in cm1.c to comment out the call to cm_server_status. By doing this, the cm1 program does not failback the connections automatically, thus allowing the administrators to control when the failback occurs (when they execute the failback sequence mentioned above). 6.2 README fileThe README file (README.nt in Windows) refers Open Client™/Open Server version 12.5. Replace all references to OCS-12_5 to $SYBASE_OCS (%SYBASE_OCS% in Windows), and set the value of $SYBASE_OCS (%SYBASE_OCS% in Windows) to OCS-15_0. 7. Technical supportEach Sybase installation that has purchased a support contract has one or more designated people who are authorized to contact Sybase Technical Support. If you have any questions about this installation or if you need assistance during the installation process, ask the designated person to contact Sybase Technical Support or the Sybase subsidiary in your area. 8. Other sources of informationUse the Sybase Getting Started CD, the SyBooks CD, and the Sybase Product Manuals Web site to learn more about your product:
8.1 Sybase certifications on the WebTechnical documentation at the Sybase Web site is updated frequently. Finding the latest information on product certifications
Finding the latest information on component certifications
Creating a personalized view of the Sybase Web site (including support pages)Set up a MySybase profile. MySybase is a free service that allows you to create a personalized view of Sybase Web pages.
8.2 Sybase EBFs and software maintenanceFinding the latest information on EBFs and software maintenance
9. Accessibility featuresThis document is available in an HTML version that is specialized for accessibility. You can navigate the HTML with an adaptive technology such as a screen reader, or view it with a screen enlarger. OpenSwitch version 15.0 and the HTML documentation have been tested for compliance with U.S. government Section 508 Accessibility requirements. Documents that comply with Section 508 generally also meet non-U.S. accessibility guidelines, such as the World Wide Web Consortium (W3C) guidelines for Web sites.
Note: You might need to configure your accessibility tool for optimal use. Some screen readers pronounce text based on its case; for example, they pronounce ALL UPPERCASE TEXT as initials, and MixedCase Text as words. You might find it helpful to configure your tool to announce syntax conventions. Consult the documentation for your tool.
|
|||||||||||
