| Sun Java System Content Delivery Server Capacity Planning Guide |    
|
| C H A P T E R 1 |
|
System Architecture |
This chapter provides a systemic view of the Sun Java
System Content Delivery Server architecture. The chapter focuses on how the different system components of Content Delivery Server relate to one another and how they map to logical and physical network and computational resources.
This chapter covers the following topics:
The overall performance of content delivery, from the provider to the subscriber, involves the combined individual performances of all the components of a content delivery environment. The Content Delivery Server works in conjuction with many other components, such as servers, browsers, integration components, operating systems, and others as shown in FIGURE 1-1:
FIGURE 1-1 Content Delivery Environment
When you examine the overall performance of content delivery, you must consider all the components involved in the content delivery environment. Determining performance of an entire content delivery environment is beyond the scope of this guide. Use this guide to determine the optimal Content Delivery Server configuration to help meet your content delivery needs.
The Service Delivery Network (SDN) architecture blueprint was used to create the systemic view of Content Delivery Server architecture. This is a well-tested system architecture well suited for the services provided by Content Delivery Server. The architecture uses the notion of service modules and service domains.
A service domain consists of a logical grouping of computer systems necessary to provide services. For instance, a Content Delivery Server administration domain might consist of the Catalog and Vending Manager Console components deployed to one or more computers.
A service module is comprised of one or more service domains and the physical computer systems and network connections of the production network. The mapping of a service domain into a service module establishes the mapping of software components to physical resources.
A deployment of Content Delivery Server usually requires integration with a number of external services. In reality, several individual service modules probably provide these external services. However, this document’s main concern is on how the quality attributes of the external systems affect the integrated content delivery system. For the sake of simplicity, this discussion assumes that a single service module, called the External Services Module, provides them all. How best to deploy the external services to provide the required level of quality is beyond the scope of this document. Having made this simplification, the typical content delivery system consists of the following service modules:
The External Services Module is comprised of service domains for the following types of services:
The configuration of these services is generally beyond the scope of this document. The following sections discuss how their quality attributes influence the quality of the integrated content delivery system.
Core network services such as DNS, are essential to the operation of the content delivery system. This guide assumes that such services are highly available.
A typical content delivery system requires integration with a wireless application protocol (WAP) gateway. The Sun Java System Content Delivery Server Customization Guide describes how to perform this integration.
The administrator of the WAP gateway must consider the incremental load generated by the content delivery system. Once you have estimated the load on Content Delivery Server, you must estimate the portion of the load that will pass through the WAP gateway. The reliability, availability, and security of the WAP gateway directly impacts your content delivery system. Other gateway services to consider include firewall, SSL proxy, web cache, and so on.
Usually you must configure a firewall to allow and to control access to Content Delivery Server. The firewall must have the capacity to handle the traffic generated by the content delivery system. For configurations using HTTPS, a SSL proxy with hardware acceleration (for example, Sun Fire B10p SSL proxy blade server) can substantially improve system performance. The configuration of a web cache can also improve performance, although it has limited impact on Content Delivery Server device portal, which almost exclusively uses dynamic pages and only a few images.
A typical content delivery system configuration requires the use of SMS, MMS, and email messaging services. The Sun Java System Content Delivery Server Customization Guide describes how to perform this integration.
The administrator of the messaging services must consider the incremental load generated by the content delivery system. To estimate this load, you need to consider how you will be using Content Delivery Server features depending on the different messaging services. For instance, if you plan to use the campaign features, you must expect a relatively high volume of outgoing messages. General recommendations cannot be made because usage can vary significantly depending on the configuration and usage of the content delivery system.
The reliability and availability of the messaging services affect the delivery of messages to and from Content Delivery Server. The Content Delivery Server does not drop messages if a messaging service is temporarily unavailable. However, Content Delivery Server generally has no mechanisms to detect message loss within the messaging services or the network. While message loss does not affect the operation of Content Delivery Server, it could have a negative impact on business operation (for example, customer reclamation).
A typical content delivery system requires integration with external operations and business support systems. Examples of such systems include billing and rating systems, customer care systems, system-monitoring systems, and so on. The Sun Java System Content Delivery Server Customization Guide contains information about how to perform such integrations.
The administrator of these systems must consider the incremental load generated by the integration of Content Delivery Server. The load estimates depend on the integration implementation, making it difficult to provide general recommendations.
The reliability and availability of OSS and BSS systems influence Content Delivery Server. The impact depends on the configuration. For instance, if the integration requires a real-time call to a rating engine, the performance and availability of Content Delivery Server is directly constrained by the performance and availability of the rating engine.
A content delivery system often requires integration with an existing LDAP subscriber directory. The Sun Java System Content Delivery Server Customization Guide describes how to perform this integration. The configuration of the directory service is generally beyond the scope of this document.
The administrator of the directory service needs to take into account the incremental load generated by Content Delivery Server. Because Content Delivery Server primarily uses LDAP for user authentication, you can estimate the load by estimating the frequency of subscriber sessions. Content Delivery Server also uses the directory to access and sometimes, to update the subscriber profile data. However, this usage is generally relatively light and you can account for it by increasing the estimate for authentication usage (for example, 10-30%, depending on the degree to which you use Content Delivery Server to manage subscriber data).
Because Content Delivery Server relies on the directory service for subscriber authentication, it is important that the directory service is readily available.
While the Database Module can physically be implemented using existing resources, this guide assumes that the database is a dedicated resource for Content Delivery Server usage.
The Database Module consists of a single service module running the database software (for example, Oracle10g). For a trial, a straightforward database installation is sufficient. For a commercial content delivery system, implement this service domain using a pair of servers clustered for high availability, and running Oracle9i or Oracle 10g, and Oracle Real Application Cluster (RAC) software. If needed, you can purchase a fully configured database system through the Sun Customer Ready Systems (“Sun CRS”) program. Contact your Sun CRS program representative for more information.
Content Delivery Server database stores information about subscribers, devices, and content. It also records download, purchase, and other events in the database. For a commercial content delivery system, you must implement proper backup and replication procedures to protect this information.
To maintain data security, run the database on hardware that is separate from the rest of Content Delivery Server, and place it on a different network segment that is not directly accessible to your subscribers, developers, customer care agents, or Catalog Manager and Vending Manager administrators. The Sun Java System Content Delivery Server Installation Guide describes how to set up the database.
The Distribution Module provides connectivity between the Content Service Module, the Database Module, and the External Services Module. It can be implemented using redundant load-balancing switches or through software load-balancing solutions. The design of the distribution module is beyond the scope of this document.
The Content Service Module is where you deploy Content Delivery Server managers:
The managers represent a logical view of Content Delivery Server. From a component perspective, the implementation of each manager consists of a database schema and a collection of web applications and services. The web applications execute in application server instances, while the services run as standalone Java technology-based applications (“Java applications”). The Sun Java System Content Delivery Server Installation Guide provides an overview of the different components and explains how they are associated with the three kinds of managers.
When you are designing the Content Service Module, first decide on how many managers you need, and which application components you need for each manager. The next step is to organize the application components into service domains. Each service domain is made up of several computer systems, each running one or more of Content Delivery Server’s application components. A deployment constitutes the collection of components required for a service domain on a single physical or virtual computer. A deployment is created using the cdsi deploy command. The Sun Java System Content Delivery Server Installation Guide provides detailed information about how to create a deployment.
There is no direct mapping of a service domain to a manager. You can place components associated with different managers in the same service domain, and components associated with the same manager in different service domains.
In the simplest configuration, the Content Service Module contains a single service domain, running all the web and service application components you need for your content delivery system. However, as the following discussion shows, there are many reasons to define multiple service domains, each running a subset of the application components provided by Content Delivery Server.
The decisions you make regarding service domains have a big impact on system quality attributes such as security, manageability, and reliability. To complete the design of the Content Service Module, you must map each service domain to physical resources.
When you design your service domains, think about the following issues:
For most content delivery systems, a single deployment (that is, a single application server instance on a single computer) including the Catalog Manager Console web application is sufficient. If necessary, this domain can be scaled either vertically (adding CPUs and memory resources) or horizontally (server load balancing over multiple instances).
If you have multiple administrators performing the same tasks concurrently, some confusing situations can occur when they operate on the same data. For instance, two administrators might try to publish the same content item. Only one of them can succeed, while the other encounters an error. Because of latencies in cache synchronization, this type of situation can occur more frequently in a horizontally scaled environment.
To ensure availability of the catalog administration service, you can deploy two or more instances and configure server load balancing with a load-sharing or failover policy. Alternatively, you can use a clustering or other kind of management solution to configure automatic restart or fail-over.
If security considerations permit, you can deploy the Catalog Manager Console with the Vending Manager Console in a single administrative domain. If you consider content submission as an internal function, you might also want to include the Developer Portal.
Although it is possible to do so, you should not combine the externally facing subscriber and developer services with internally facing administration services. Instead, provide the externally facing services using separate service domains. Combining externally and internally facing services complicates firewall configuration and could compromise security.
The deployment guidelines for a Vending Manager Console are the same as for the Catalog Manager Console. You can combine a single Vending Manager Console with the Catalog Manager Console in a single service domain. However, if you have multiple Vending Managers, you must create a separate service domain for each of the Vending Manager Consoles.
For most service delivery systems, the guidelines for the Developer Portal are similar to those for the Catalog and Vending Manager Administration Consoles. A single instance providing the Developer Portal web application is usually sufficient, but you might want multiple load-balanced instances for the sake of scalability and availability.
If you consider content submission an internal function, you might want to include the Developer Portal and the Catalog Manager Console in the same service domain.
For each Vending Manager, you need one or more Subscriber Portals. Many content delivery systems have at least two Subscriber Portals. Most deployments have a Web Portal for Internet users using desktop clients and at least one device portal. The reason you might need more than one device portal is that devices can have more than one way of accessing the portal, with different authentication requirements. For instance, devices can access the portal through a WAP gateway, using HTTP headers set by the WAP gateway for authentication. If the portal is also accessible directly through HTTP, using username and password authentication, it is important to prevent device spoofing. While your firewall might be capable of filtering out HTTP requests containing the HTTP headers used by the WAP gateway for authentication, a simpler and safer solution is to provide separate service domains. This way, the service domain configured to accept HTTP header-based authentication is visible only to the WAP gateway and is shielded from the Internet.
The Subscriber Portal is well suited for either vertical or horizontal scaling. This makes it easy to add resources to be able to support a growing subscriber base. Horizontal scaling makes it easy to ensure availability by running instances on different servers or system domains. Horizontal scaling offers a cost efficient solution for small to mid-size deployments. Combining horizontal scalability with vertical scalability might be a good solution for larger deployments. By consolidating many small servers into fewer larger servers, you can reduce space, power consumption, and simplify system management.
Like the Subscriber Portal, the Fulfillment Manager application is well suited for vertical or horizontal scalability. For better resource utilization, you might want to combine the Fulfillment Manager application with a Subscriber Portal configured for HTTP access.
You need at least one Java Message Service (JMS) broker per Vending Manager, and at least one per Catalog Manager. The Catalog Manager can share JMS brokers with one Vending Manager. By default, any deployment including at least one of the web applications will have its own JMS broker. This configuration guarantees the highest degree of availability, but it might complicate integration with a billing system, because each deployment becomes a separate source of events. This can be especially difficult in a horizontally scaled environment. To simplify the integration, you can choose to use a shared broker configuration. In the case where the Catalog Manager and the Vending Manager run on separate servers, use a single broker per service domain or a single broker per Vending Manager.
You can specify what JMS broker to use for each deployment. If you are using the WebLogic application server, you can do this by specifying the Java Naming and Directory Interface (JNDI) API service address in the deployment configuration file. If you are running the Sun Java System Application Server, you can specify a JMS broker for each deployment by specifying an external JMS broker when running the deploymq.sh utility. See the Sun Java System Content Delivery Server Installation Guide for details about deployment configuration.
Multivending deployments and the following service applications depend on the JMS configuration:
If you are using the default JMS configuration, each of these applications can be included and executed as part of every deployment of every service domain.
However, if you have chosen a shared broker configuration, you must run at most one instance of each of these applications per JMS broker.
For each JMS broker, choose the deployment for which the broker is the default broker and add the required services (postpaid and messaging are dependent on the event service). If you are using the Sun Java System Application Server and external JMS brokers, this might not be possible. In that case, define a service domain for these services, and possibly other application components for which the strategy of specifying a JMS broker for each deployment is suitable.
For each Vending Manager, you can add the push listener and confirm listener services to either a service domain containing a corresponding Subscriber Portal, Fulfillment Manager, or Vending Manager Console, depending on which one best matches the scalability requirements for you particular listener implementation. Alternatively, you can create a separate service domain.
Special care should be taken if your listener implementation does not support running more than one instance at a time. If it does not, do not add the listener to a service domain that you intend to scale horizontally. At least make sure not to execute the listener as part of more than one deployment in the domain.
You must run exactly one instance of the Notification Service per Vending Manager. As long as you are careful not to replicate this service, you can add it to the service domain containing the Vending Manager Console.
No matter how you design your service domains and no matter what your JMS configuration is, you can always include the Monitoring Service application as part of every deployment of every service domain. However, if you plan to run the Monitoring Service as part of multiple service domains mapped to the same physical computer, you must configure different port settings for each domain.
Each instance of the Catalog Manager and Vending Manager has an instance of the search service. The default setup has the Catalog Manager search service deployed along with the Catalog Manager instance. The same setup applies to the Vending Manger.
However, the search server can be deployed on a completely different service domain and the Catalog and Vending Managers can point to this external search service. By having the search service on a separate service domain for both the Catalog and Vending Managers, improved performance results for both managers.
| Sun Java System Content Delivery Server Capacity Planning Guide | 820-1939-10 |
|
Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved.