Juniper MEDIA FLOW CONTROLLER 2.0.4 -, Administrator'S Manual

Page: 48 / 400

Media Flow Controller Overview Media Flow Controller Administrator’s Guide
48 Media Flow Controller Delivery Methods Copyright © 2010, Juniper Networks, Inc.
Connection Pooling
A connection pool is a list of origin-side open connections maintained so they can be reused
for additional data requests. Connection pools enhance the performance of executing
requests made to a dynamic database-driven Website application. In connection pooling,
connections from Media Flow Controller to origin are placed in a pool and used over again so
that a new connection does not have to be established from Media Flow Controller to origin for
each client request for content not in cache. If all the origin-side connections are being used, a
new connection is made and is also added to the pool. This cuts down on the amount of time a
user must wait to establish a connection. You use the
delivery protocol CLI commands to
control connection pooling.
Consistent Hash-Based Clustering and Origin Escalation
Media Flow Controller provides a configuration to use a consistent hashing scheme to bind
objects to nodes using an XML file server map. Additionally, you can create an origin-server
node map for origin escalation: if the target origin-server fails, another configured origin-server
is automatically chosen. Both of these configurations are achieved through the creation of a
server-map (format-type cluster-map and format-type origin-escalation-map) that is then
associated with a namespace.
Note! The hash scheme and origin server data distribution must be pre-configured.
A consistent hash scheme is used by the Media Flow Controller with the cluster-map node
definitions (and, optionally namespace cluster-hash configuration) to map to the target
origins. In the case where no origins exist due to network connectivity issues, an alternative
set of origin servers can be consulted via an origin-escalation-map, or another cluster-map,
to resolve the request. Consistent hash-based cluster properties are as follows:
•
No inter-cache communication required.
•
Ability to identify the target node via strict computation.
•
Uniform distribution amongst the nodes.
•
Object stickiness after cluster re-configuration.
• After a node deletion, existing entries map to the same node and objects associated
with the deleted node are uniformly distributed amongst the remaining nodes.
• After an addition of a preexisting node, entries map to the same nodes as observed
prior to the node deletion.
• After an addition of a new node, an equal portion of the address space is remapped to
the new node resulting in a uniform distribution amongst the nodes. Existing entries
may be moved to the new node.
Origin escalation is a configuration consisting of <N> origin servers which are logically viewed
as one, where requests are sequentially initiated to specific origin servers (based upon a
configured weight), until the request is satisfied or all known available origin servers at
request initiation time have been tried. An origin server request is re-initiated to the next
configured origin server (escalation) when network connectivity errors are received or when a
specific, configured, origin server response code is received (for example, HTTP 404).
You can use these two server-map types together to create a server hierarchy of server-maps
consisting of multiple instances of cluster-map and origin-escalation The order of in which
the maps are added to the namespace denotes the order in which they are read.
See Chapter 7, “Server Map Configuration,” for more details including requirements.