Streaming Media Supplement sa2150 and sa2250

15
Chapter 2 Media-IXT Deployment Scenarios
Understanding clustering
Media-IXT supports management-only clustering.
In management-only clustering mode, Media-IXT cluster nodes share configuration information, so that all
nodes can be administered at once. A multicast management protocol allows you to work with a single system
image of the Media-IXT cluster.
The HP Cache Server Appliance Administrator Guide describes management-only clustering, as well as
another clustering mode, full clustering, which is only supported for HTTP, and not supported for streaming
media protocols. In full-clustering mode, besides sharing configuration information, a Traffic Server cluster
distributes its cache across its nodes, creating a single, virtual object store.
Understanding VIP failover
In a Media-IXT cluster, a pool of virtual IP addresses is assigned to the nodes in the cluster. When one node
fails, other nodes must take over the traffic going to the down node’s virtual IP addresses.
The node with the lowest IP address can assign another node to take over the traffic that would normally go to
the down node. This technique is called VIP failover (the VIP stands for Virtual IP address). The failover may
not complete quickly enough to avoid adding latency to client requests.
Understanding selective caching
Using selective caching, you can specify criteria to determine whether content is proxyable or not, and
cacheable or not.
When content is not proxyable, Media-IXT denies the client connection, with an appropriate message to the
client (if possible).
When content is not cacheable, Media-IXT goes into passthrough mode and proxies, but does not cache, the
content.
See the HP Cache Server Appliance Administrator Guide for more information about selective caching.
Two configuration files control selective caching:
• cache.config controls cacheability
• filter.config controls proxyability
Selective caching and reverse proxy for multiple origin servers
Selective caching is used in a special way in deployments where Media-IXT performs reverse proxy for
multiple origin servers, each representing a different website, and where Media-IXT should not service requests
for any other origin servers.
Let’s say that you deploy Media-IXT to perform reverse proxy caching for three websites, whose advertised
names are alpha.com, beta.com and delta.com.
• First you configure reverse proxy caching for each website.
• Then you configure selective caching, placing a rule in each configuration file for each origin server, such
that content from that server is proxied and cached.
• Finally, you place general rules (using wildcard characters) saying not to cache and not to proxy content for
any origin server, in the selective caching configuration files.
For each client request, Media-IXT reads the configuration files from top to bottom, so that requests for content
from alpha.com, beta.com and delta.com match the first rules, and Media-IXT serves these requests.
Requests for content from any other origin servers only match the general rules, which say not to proxy or cache
content, so Media-IXT does not serve those requests.