The delivery of either real-time or delayed feed streaming media can be very compute intensive on the resources of object servers. As we saw in Chapter 3, the delivery of streaming audio and video data requires not only the use of a combination of TCP- and UDP-based delivery channels, but also potentially the interpretation and encoding of a live video or audio feed. The attraction of load balancing standard HTTP traffic is increased many fold when you consider the horsepower required to deliver high quality media streaming. However, as we've seen with other multithreaded protocols such as FTP, the load balancing of RTSP has issues all its own. Load Balancing RTSP at Layer 4 OnlyBefore we look at the subtleties of RTSP load balancing at Layer 7, let's look at the basic frame flow when we use Layer 4 only. Figure 6-18 shows the basic traffic flow for Layer 4 load balancing of RTSP and RTP traffic. If we consider the steps in turn , we'll see where the problem lies.
Figure 6-18. One of the main issues with load balancing RTSP at Layer 4 only is that the real IP addresses of the object servers are "bled" back to the client, as the corresponding RTSP and RTP streams are not associated in the content switch.
The net result of this type of configuration can be summarized as IP address bleeding , whereby the real source IP addresses of the object servers are revealed to the client on the UDP streams carrying the video and audio data. In many instances, this might not create a problem, as the RTSP and RTP specifications do not require that the source address of the RTP delivery be the same as the destination IP address for the RTSP connection. Where this might cause issues is in the following scenarios:
Therefore, our golden rule for implementing the Layer 4 only server load balancing for RTSP as described is to locate the servers in public routable address space such that once the source IP address bleeding occurs, fewer problems will be experienced . Applications of Layer 7 RTSP Load BalancingAdding Layer 7 intelligence to the load balancing of video and audio streaming services with RTSP has a number of applications. Some are less obvious and simply improve the overall operation while others can have tangible benefits in improving how different video and audio content types are delivered. Tying RTSP, RTP and RTCP Channels TogetherThe first application we'll consider is a solution to the issue described in the preceding section. The correct source IP address translation will provide the client application with the illusion that both the RTSP connection and the consequent RTP and RTCP streams all originate to and from the VIP on the content switch. Without describing in detail the individual workings of specific vendor implementations, the basic traffic flow can be seen in Figure 6-19. Figure 6-19. Once the content switch has parsed the RTSP data, it can create the relevant session entries to ensure the reverse NAT takes place for the RTP streams.
The basic stages of the traffic flow as shown in Figure 6-19 are as follows :
While each vendor's implementation of Layer 7 RTSP parsing for this type of issue may differ slightly, the fundamental outcome remains the samethe object servers from which the RTP content will be delivered can now reside in RFC 1918 non-routable address space, and the content switch will ensure that none of these addresses appear to the outside world. Parsing the URL of the RTSP StreamAs we saw earlier in the chapter for HTTP content, there are often many good reasons to separate different content types across backend object servers. In the case of RTSP-based video and audio streams, this reasoning is often accentuated, as different stream types will require different resource types. Live video streaming, for example, requires large amounts of processing power in terms of CPU and memory to allow the object server resources to convert the live video and audio in the correct compression and format for delivery to the client, as well as access to the live feed itself via directly attached cameras , satellite feeds, or TV type input. Static, or prerecorded, might typically require less power CPU and memory resources, as the compression and encoding will already have taken place during the recording and positioning of the content. This type of service might more typically require NFS or SAN access to large data stores containing the prerecorded movies, programs, and clips. Other requirements may be to separate out free versus pay-on-demand content, authenticated versus nonauthenticated content, or even using the URL to distinguish between paying customers in a shared hosting environment. Whatever the requirement, the ability to parse the URL being passed within the RTSP stream can be a very powerful addition to a media streaming implementation. Figure 6-20 shows an example of separating live and prerecorded streams on the object servers using a content switch. Figure 6-20. A content switch parsing the DESCRIBE commands of an RTSP stream offers the ability to separate different content types such as live and prerecorded streams.
In the same way that FTP requires intelligent parsing and translation of IP addresses and TCP ports, and HTTP offers the ability to segregate content types, Layer 7 RTSP load-balancing combines both of these requirements and capabilities. With RTSP being an open, RFC defined protocol, many content switch vendors now offer support for the mechanisms described previously. |