Transcription
Tech BriefMeeting the Challenges ofan HA Architecture for IBMWebSphere SIPVoice and multi-media features available in IBM WebSphereApplication Server enable a new generation of integratedapplications but also introduce new challenges for IT staff.The inclusion of F5 BIG-IP LTM as a core component of ahigh availability SIP deployment addresses those challengeswithout increasing network complexity.by Lori MacVittieSenior Technical Marketing Manager
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPContentsIntroductionPrerequisite Knowledge and Terminology33HA SIP Challenges5General HA Architecture5Technical Architecture8Conclusion92
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPIntroductionFor any network service, high availability is desirable, and it is absolutely mandatoryfor business continuity in many organizations. Such organizations’ increasing relianceon SIP (Session Initiation Protocol) to enable communication between employees,partners, and customers elevates the importance of ensuring a high availability (HA)environment.In recognition of that reliance, IBM introduced a SIP container into version 6.1 of itsWebSphere Application Server (WAS). This included support for JSR 116—the SIPServlet 1.0 API. JSR 116 enables developers to create services such as back-to-backuser agents (B2BUA) and proxy-based applications.An HA environment for proxies, however, involves several challenges. Thesechallenges can be met with configurations of F5 BIG-IP Local Traffic Manager (LTM) in a WebSphere SIP deployment.F5 products and IBM WebSphere SIP proxies may be integrated into many possiblearchitectures to deploy an HA environment for SIP-based communications. Ahigh-level illustration of the most common architectures and configurations can beuseful for discussion but should not be considered an exhaustive study of all possibleintegration and configuration options. Detailed configuration information is availablein the respective manuals for BIG-IP LTM and IBM WebSphere Application Server.Prerequisite Knowledge and TerminologyAn HA SIP deployment with F5 technologies requires general familiarity with SIP,high-availability architectures, and IBM WebSphere Application Server as well asa basic understanding of the workings of SSL and a working knowledge of loadbalancing techniques, functions, and features. A few common abbreviations,general SIP terms, and product-specific references include:Proxy: A proxy is a server or network component that forwards a request on behalfof the requestor. A proxy can be stateful or stateless. A stateless SIP proxy does notmaintain the state of the SIP request or monitor the transaction once it is forwardedto the next hop (node). A stateful proxy does just the opposite, tracking andmaintaining the transaction state throughout the session.User Agent Client (UAC): A UAC creates a request or initiates a dialog.User Agent Server (UAS): A UAS handles a request or dialog.3
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPBack-to-Back User Agent (B2BUA): A B2BUA is a converged UAS/UAC thatmediates a dialog. A B2BUA terminates SIP sessions, acting as the ultimate endpoint,and duplicates the dialog with the actual client. This is often used to enable SIPwhen end-points are within protected networks, that is, when NAT is in use. Inservice provider networks, a B2BUA would be referred to as a session bordercontroller (SBC).F5 BIG-IP LTM: An F5 product used to provide load balancing and applicationdelivery services for a particular web service or other application. BIG-IP LTMmanages traffic in a data center or a group of servers.Virtual IP address (VIP): An F5 term for a host representing a resource managedby BIG-IP LTM.Secure Network Address Translation (SNAT): SNATs are used when trafficoriginates inside a protected network and must be translated to a VIP or externalnetwork address to enable bidirectional communication.UACuser@ibm.comUASB2BUAibm.comSIP proxyUACexample.com user@example.comSIP proxySIP example.comINVITEuser@example.com100 TRYING100 TRYING180 RINGING180 RINGING200 OK200 OKINVITEuser@example.com180 RINGING200 OKACKCOMMUNICATION SESSIONBYEFigure 1: SIP sessions use proxies to mediate communication between clients across protectednetwork boundaries.4
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPHA SIP ChallengesThe challenges associated with enabling an HA environment for proxies are threefold. First, the HA service provider must be able to accurately monitor andsubsequently detect an outage. For SIP communications, this requires a more specificdata exchange than is often used in simple HTTP monitoring.Second, because there may be more than one active SIP proxy, the HA providermust accurately route existing communications to the SIP proxy through which thesession was originally established. This requires the insertion of persistence into thearchitecture at the load balancing service, which in turn necessitates the ability toperform deep content inspection on both secured and unsecured SIP protocol traffic.Finally, SIP, like many of its UDP-based predecessors, introduces unique challengesfor proxies and load balancing services. SIP services assume direct, bidirectionalcommunication between parties. Network data (IP and port) must be known priorto traversal through upstream routing devices, because they are encoded in thepayload. This requirement is often met by the use of SNAT to ensure traffic is routedproperly back through the network. The challenge with this technique is anephemeral port constraint, limiting SNAT options to fewer than 65,000—a limit thatis often exceeded even in modest SIP deployments because of the protocol’s heavyreliance on multiple ports per session. Use of the Via header, which specifies a trailof upstream proxies, provides one solution by allowing proper reverse traversal ofthe network without imposing the capacity-limiting constraints of SNAT.With the appropriate architecture and configuration, BIG-IP LTM in a WebSphere SIPdeployment can overcome these challenges to provide high availability whilesupporting secured and unsecured communications.General HA ArchitectureA high-availability environment for SIP when using IBM WebSphere ApplicationServers and proxies requires the configuration of replication domains to enablememory-to-memory replication between SIP containers. This ensures a nondisruptive failover of proxy to proxy or server to server—what is often known moregenerally as a stateful failover.5
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPIBM SIP proxies, as noted earlier, are stateless. Therefore the pair of BIG-IP LTMdevices providing load balancing services is also charged with providing persistenceto ensure proper routing of communication to the proxy and server on which thesession was originally established.IBM WebSphere—Chassis 1Blade 1SIP Proxy 1Blade 2Blade 3BIG-IPLocal Traffic ManagerBIG-IPLocal Traffic ManagerBlade 4SIPWAS 1WAS 2WAS 3WAS 4WAS 5WAS 6IBM WebSphere—Chassis 2Blade 1SIP Proxy 2Blade 2Blade 3Blade 4WAS 1WAS 4WAS 3WAS 5WAS 2WAS 6Figure 2: A high-availability architecture with BIG-IP LTM and IBM WebSphere.Figure 2 shows a high-availability architecture with F5 BIG-IP LTM devices and twoIBM SIP proxy servers using IBM blade chassis, each housing four blade servers. Inthe first chassis, the WebSphere ND Deployment Manager runs on the same bladeas the SIP Proxy. The remaining three blades contain two application servers each.In the second chassis, the first blade contains a proxy server and the remaining threeblades contain two application servers each.In this configuration, BIG-IP LTM tracks availability of the SIP proxy servers bysending a stream of SIP OPTIONS messages at regular intervals. The proxy isexpected to respond with a 200 OK message.6
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPFor this configuration to provide the high availability required, the SIP proxy must beconfigured to accept and handle all incoming traffic from BIG-IP LTM. If the proxyserver does not respond in a pre-determined amount of time, BIG-IP LTM interpretsthis lack of response as an acknowledgement of an inactive or disabled proxy server.BIG-IP LTM discontinues forwarding client traffic to the proxy, but continues to sendOPTIONS requests to the server. If and when the proxy server responds with a 200OK message, BIG-IP LTM will re-enable the proxy and again route requests to it.For this process to work, the WebSphere SIP Proxy must be configured to expectOPTIONS messages from BIG-IP LTM. In addition, a set of SIP proxy-specific customproperties must be present and configured to enable interoperability betweenBIG-IP LTM and the WebSphere SIP proxy server.Figure 3: The WebSphere SIP proxy settings required to communicate with BIG-IP LTM.7
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPTechnical ArchitectureThe architecture required to implement a high-availability SIP environment comprisesmultiple virtual servers, pools, and monitors on BIG-IP LTM. This is necessary tosupport use of both TCP and UDP with a secured (TLS) and unsecured traffic mix.The SIP proxies are instances of WebSphere with its “Proxy Mode” installed andconfigured. The application servers are also WebSphere servers with the “SIPPersona” enabled. BIG-IP LTM is configured as a SIP proxy to fully participate in theflow while providing HA and load balancing services. See Figure 4.IBM WebSphere—Chassis 1Blade 1SIP Proxy 1Blade 2Client SSLBlade 3BIG-IPLocal Traffic ManagerUDP VIPTCP VIPTLS TCP VIPBlade 4WAS 1WAS 2WAS 3TLS SIP POOLSIP POOLUDP and TCPSIP MONITORSWAS 4WAS 5WAS 6SIPBIG-IPLocal Traffic ManagerServerSSLIBM WebSphere—Chassis 2Blade 1SIP Proxy 2Blade 2WAS 1WAS 4TLS SIP POOLSIP POOLBlade 3Blade 4WAS 3WAS 5UDP and TCPSIP MONITORSWAS 2WAS 6Figure 4: This BIG-IP LTM configuration enables an HA environment with WebSphere SIPproxies.In this architecture, BIG-IP LTM serves as the initial SIP proxy—a B2BUA—to whichclients connect. In addition to monitoring the IBM SIP proxy instances for availability,BIG-IP LTM is also responsible for managing SIP sessions to ensure proper routingthroughout the life of the session. On an initial connection (handshake), BIG-IP LTMwill select an appropriate SIP proxy, insert a Via header, and store a mapping ofCall-Id to the SIP proxy in its session state table to ensure all subsequent messagesrelated to that call session are consistently routed to the same SIP proxy.8
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPThe decision on which SIP proxy is appropriate can be as simple as selecting a nodebased on an industry standard load-balancing algorithm or it can be highly complexand based on both the ability of BIG-IP LTM to extract SIP variables and itsmonitoring of the health, current capacity, and performance of the SIP proxies. Forexample, BIG-IP LTM can be configured to route high-priority calls to the SIP proxywith the lightest load to ensure the fastest possible response.When managing encrypted communications, BIG-IP LTM terminates the securesession and performs the same inspection and insertion process. This effectivelyoffloads the cryptographic processing burden from the SIP proxies and improvesoverall performance by executing that processing in a hardware-acceleratedenvironment. This offloading has a cascading effect on the performance and capacityof the SIP proxies by freeing up resources that can be used to service other clients andperform SIP-specific processing. If required by operational policy, BIG-IP LTM willre-encrypt the session before forwarding it to the appropriate SIP proxy.In the event a SIP proxy becomes unavailable based on the configured monitoring,BIG-IP LTM will stop forwarding requests to the disabled proxy until it hasresponded appropriately. In the interim, BIG-IP LTM routes requests to availableproxies and, by virtue of the session replication configured at the application serverlayer, conversations will continue uninterrupted. Unlike many load balancing servicesfor SIP that monitor only the availability of the port on the SIP proxy, BIG-IP LTM canensure that SIP services are not only available but executing correctly byunderstanding SIP and inspecting responses to ensure their correctness.ConclusionThe deployment of multi-media features such as VoIP on traditional platforms willcontinue to increase as development platforms broaden their support for the protocolsrequired to develop integrated applications. The challenges associated with theseoften more complex communication protocols can arise when high availabilityarchitectures are introduced. The nature of stateless proxies requires a mechanism bywhich sessions can be appropriately routed during both normal operation and afailover event. This mechanism requires sufficient capabilities to inspect and correctlyinterpret protocol-specific payloads as well as intelligent monitoring of downstreamservices for availability. The sensitivity of SIP to interruptions is high, causing call qualityto degrade.9
Tech BriefMeeting the Challenges of an HA Architecture for IBM WebSphere SIPIncorporating BIG-IP LTM as part of a WebSphere SIP implementation helps avoiddegradation in the quality of communications that are increasingly critical tobusiness operations. BIG-IP LTM helps safeguard the ability to connect withcustomers by intelligently monitoring the health of WebSphere SIP proxies andre-routing communications when necessary. By inspecting both unsecured andsecured communications, BIG-IP LTM ensures proper routing of sessions and furthereliminates limitations imposed by the use of SNAT at the network layer withoutincreasing complexity at that layer.BIG-IP LTM is an integral component in a WebSphere SIP deployment, providing thenecessary intelligence and control required to scale seamlessly and handle effortlessly,without disruption, what would otherwise be highly noticeable failures.F5 Networks, Inc. 401 Elliott Avenue West, Seattle, WA 98119F5 Networks, Inc.Corporate Headquartersinfo@f5.comF5 NetworksAsia-Pacificapacinfo@f5.com888-882-4447F5 Networks .comF5 NetworksJapan K.K.f5j-info@f5.com 2012 F5 Networks, Inc. All rights reserved. F5, F5 Networks, the F5 logo, and IT agility. Your way., are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5 trademarks are identifiedat f5.com. Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or affiliation, express or implied, claimed by F5. CS01-00085 0212
Figure 2: A high-availability architecture with BIG-IP LTM and IBM WebSphere. Figure 2 shows a high-availability architecture with F5 BIG-IP LTM devices and two IBM SIP proxy servers using IBM blade chassis, each housing four blade servers. In the first chassis, the WebSphere ND Deployment Manager runs on the same blade as the SIP Proxy.
