Capacity Planning of SOA-Based Systems - Service Technology ...

More documents

Recommendations

Info

SOA in the Telco Domain Part II: Capacity Planning of SOA-Based Systems Service Technology Magazine (Issue LIV , September 2011) Enterprise Services Bus Capacity Planning The Enterprise Service Bus is a system where collections of services are running to do mediation, routing, transformation, and orchestration to process incoming request into desired results. From the previous chapter, we already know what the requirements of a service can be ran on. Afterwards, we sum up together those requirements and they become requirements for Enterprise Service Bus capacity planning. In telecommunication domain, 5-9 high availability is a mandatory attributes. Enterprise Service Bus (ESB) should able to serve all requests 24 hours a day. To keep availability of the ESB, we should have a good capacity planning and high availability strategy for it: 1. Processing unit on one ESB should not exceed a number of threshold depends on policy we use. 2. Memory unit of ESB should have adequate free paging space to serve services that needs more memory allocation. 3. Network bandwidth should be big enough to distribute certain transaction loads packet to the SOA system (ESB, Messaging Bus, Database, Service Providers, etc). 4. High availability strategy must be able to support sustainability of the ESB system in order to serve the request. For example, our system consists of four ESBs. The threshold of the processing unit on each ESB depends on the policy we use: 1. One-to-one pair - means that one ESB will be a fault tolerant system for one primary ESB. In this policy, processing unit of primary ESB can be 100% capacity since the secondary ESB can only hold a single primary ESB capacity. But this approach it very expensive, so we must have a backup for every single primary ESB. Figure 3 – One-to-One Pair 2. N+1 - means that there is one ESB that is becoming the secondary ESB for all primary ESBs. If there is one ESB fails, then it should fall over to the secondary ESB. In this policy, the processing unit of primary ESB should not exceed 100/N % capacity, since the secondary ESB has to hold N-primary ESB capacity. Copyright © Arcitura Education Inc. 6 www.servicetechmag.com
SOA in the Telco Domain Part II: Capacity Planning of SOA-Based Systems Service Technology Magazine (Issue LIV , September 2011) Figure 4 – N+1 Policy Unlike the processing unit, the memory of the ESB is much more straightforward. We just need to have available paging space for services to allocate memory. For example, we have 64 GB of memory and in average our services in one primary ESB need 128 MB to runs at 150 tps. Our single primary ESB can serve until 512 services runs at 150 tps. But, we should also put a threshold for memory, not utilizing it until 100%. For example, if it was 60% memory utilized, we should put another memory unit on ESB. Messaging Bus Capacity Planning Just like the Enterprise Service Bus, capacity planning on the Messaging Bus will also include processing unit, memory, and high availability features. This creates high availability features that are more or less the same as the Enterprise Service Bus. However, the Messaging Bus’ memory unit is not as straightforward as the ESB memory unit. There are additional aspects we also need to consider, such as storage size which is for persisting messages. Capacity planning of memory on the Messaging Bus correlates with the message throughput (input and output). It will use memory to retrieve messages from the service producer and send it to the service consumer to keep the performance. For example, in our previous chapter, a message will have 12,204 bytes size. If a service producer can create the message up to the 150 tps rate, we will need at least around 1.74 MB of memory to holds the message for sending/receiving activity. Sometimes there is a condition where service consumer is not available (i.e. periodic maintenance, restarting instances). In this case, all messages that are produced by the service producer should not be send instantly, hence keeping it into persistent until service consumer become available again. With this mechanism, we will not lose any messages/transactions. The persistent size unit depends on how long the services consumer is usually unavailable, and also depends on the message rate itself. For example, service consumer in the worst case is not available for 3 hours, while the transaction loads are at 150 tps. So we will need to have 18,792 MB of persistent unit (storage). Copyright © Arcitura Education Inc. 7 www.servicetechmag.com
Page 1 and 2: SOA in the Telco Domain Part II: Ca
Page 5: SOA in the Telco Domain Part II: Ca
Page 11: SOA in the Telco Domain Part II: Ca

Capacity Planning of SOA-Based Systems - Service Technology ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?