ESRWF: Extreme State-Rank based Workload Factoring for Integrated Cloud Computing Model

Transcription

1 ESRWF: Extreme State-Rank based Workload Factoring for Integrated Cloud Computing Model Snehil Sharma 1, Abhishek Mathur 2, Shailendra Shrivastava Samrat Ashok Technological Institute (SATI) Vidisha (M.P.), INDIA 1 sharmasnehil.pub@gmail.com, 2 abhi_math2@yahoo.com, 3 shailendrashrivastava@rediffmail.com 3 Abstract Despite all the hypes, the designers of Workload Factoring solutions have consistently debated on the tradeoffs between factoring of workload and their resulting performance. When computational resources are provided to the existing system; one of the main challenges that the computing community is face dazzling workload of application requests and deteriorating performance at runtime of particular server-site. To address those concerns that, we propose an Extreme State-Rank based Workload Factoring for Integrated Cloud Computing Model. It consolidates components in Cloud infrastructure at On-Off both type premises of internet based applications. The Intelligence in this approach lies in extreme factoring of performances of system into States (Regular & Critical) during period of experiencing workload by running system and dynamically distribution of State-Rank {,, } to incoming requests at duration of particular system state in running system. We also propose ESRATE as efficient Workload Factoring algorithm with some specified features, which enables factoring of incoming oppressive requests on the basis of State, State-Rank & Request-Weight- Coefficient explicitly. Through extensive analysis with efficient simulated evaluations, we predict and showed Workload Factoring technology to achieve Request Concurrency with availability of servers, Unique Video Requested with best resource proficiency (=%), the ratio of the maximum load to the average load (=.) with formulation of speedup ( ) and Memory-Prediction-Error (ε) as well as reduced data cache and replication overhead in critical state especially. I. INTRODUCTION Cloud Computing is an emerging trends of Distributed Computing and generalization of Grid Computing known either as online services such as Amazon AWS [1] & Google App Engine [5] for enabling convenient, on-demand services access to a shared pool of configurable computing resources (e.g. Networks, Servers, Storage, Applications, and Services) that can be rapidly provisioned and released with minimal intelligent management efforts or service provider within interactions of regulations. Critics argue that Cloud Computing is not reliable enough due to the tension created by incoming oppressive requests. It has features of shared computing infrastructure for hosting multiple applications where management complexity is hidden and resource multiplexing leads to proficiency. More computing resources are allocated on demand to application when its workload incurs more resource demand than it is currently allocated. So here, we focus on Workload Factoring [16] as solution in this paper as it is a unique functionality requirement by Cloud Computing Architecture. Besides the presentation consolidation, we also proposes an term Integrated Cloud Computing Model called joint venture for all cloud deployment model described in fig.1 where enterprise and IT consultants can base to design and plan their computing platform for hosting Internet based applications with highly dynamic workload. The Cloud Computing model features two analytical ideas as: ESRWF & ESRATE for system which is naturally and randomly appeared different components in aggregate workload of internet applications. An efficient workload factoring philosophy is shaped for enabling technology of the Integrated Cloud Computing Model. Its basic function is to split & control the workload into two parts upon (unpredictable) load spikes, and assures that the critical workload incurs minimal cache/replication demand on the application data associated with it. This simplifies the system architecture design for the Critical State and significantly increases the server performance within it. As for the Regular State, workload dynamics are reduced significantly; this makes possible resource capacity planning with low over-provisioning factor and/or efficient dynamic provisioning with reliable workload prediction. We built a video streaming service and flow of request for Formularize Description and Tri-Way Trajectory Simulation as an experimental showcase of the Integrated Cloud Computing Model. It has a local cluster as the regular workload region e.g. LDC [18] and the critical workload region e.g. [1], [5]; the workload factoring scheme was implemented as a load controller to arbitrate the stream load distribution between the two states. With extensive Analysis, Observation Tracery, and Tri-Way Trajectory Simulation experiments, we

2 showed this workload factoring technology can enable reliable workload prediction in the Regular State, request rate & request rate coefficient, effective ratio of the maximum load to the average load, Memory-Prediction-Error (ε) in Critical State, achieved resource proficiency and reduce data cache/replication overhead in the Critical State, and react fast (with an speedup factor) to the changing application data popularity upon the arrival of oppressive request. The rest of paper is organized as follows: here Section-II describes the previous related work done for Workload Factoring. Section-III describes rationale for the Proposed Integrated Cloud Computing Model and proposed ESRWF respectively. For evaluation, we have to Analysis and Performance Criteria in Section-IV & Section-V respectively. We conclude this paper with future work in Section-VI. II. RELATED WORKS Amazon launches CloudFront [2] for its AWS customers (who can now deliver application load through global network) in November 2008 and after two months, in February 2009, H. Zhang, G. Jiang, K. Yoshihira, H. Chen, and A. Saxena proposed Intelligent workload factoring for a hybrid Cloud Computing model [16] with introduction to base workload zone and trespassing workload zone with formularized descriptions of Traffic- Estimation of [14], [19], [9]. Around the same time period VMWare also release the vcloud service concept [7] for Virtual Data Center Operation System as experimental view of Para-Virtualization, which helps cloud customers to leverage off-premise computing capacity. On follow this way, Berkeley researchers [17] offer a ranked list of obstacles to the growth of Cloud Computing. Similar to the points, we made in the introduction, the concerns on public Cloud Computing services include service availability, data confidentiality and auditability, performance unpredictability, and so on. On discuss SOMA (Service Oriented Model & Architecture), we believe an Integrated Cloud Computing Model makes sense to enterprise IT and can resolve many issues raised from Intrgrated Cloud Computing model. Through Content Distributed Network (CDN) and web caching workload factoring happen between a local web server and proxy servers. The typical method is DNS redirecting and the workload factoring decision is predefined manually over a set of most popular web objects. When current IT systems evolve from the dedicated platform model to the shared platform model along the cloud computing trend, we believe a core technology component is required on flexible workload management working for such models mentioned above, and our workload factoring technology (ESRWF) is proposed as one answer for it. III. PROPOSED RATIONALE : ESRWF In the proposed Integrated Cloud Computing Model, which designs also as fair arranged integration of unlimited & limited both type proposals for resolving the workload, Model defines two states for resource management: Regular State which is original & has limited resources in dedicated application platform in Local Internet Data Center (LDC) [18]. In this state all processes run all time and with balanced load of application & system. As processing the data volume doesn t vary sudden and strike after removing at high workload. The LDC is expected to run in relaxed mode and with high resource proficiency & managing facility for best utilizing scenario even though resource provisioning for QoS guarantee. Another is Critical State in which all resources in dedicated application platform operated by cloud service provider & related infrastructure. This state is provisioned on high demand and also optimizes to be on for a momentary variation of critical oppressive runtime periods. Here, Resources are provided at large scale. Each state has its local load balancing scheme managed according to workload present in runtime. The origination of model is lies in dynamic workload as Hub & Spoke Infrastructures. It addresses many concepts where IT consultants completely rely on extreme utilization of cloud services for application hosting. At some cases, we can t predict some type unexpected workload. We define it as two ways as Least Workload Left (LWL) and Maximal Workload Left (MWL). It is necessary to learn these natures of high spike& burst-time as well as find out an efficient way to handle it once such events happen. Ongoing way of Customer Resource Management (CRMs) and Information Life-Cycle Management (ILMs) with Integrated Cloud Computing Model, we identified that the resource management applied through our scheme has efficient impact to resolve oppressive workload on different components of aggregated applications during runtime as intelligent satisfaction for customers. This scheme varies in our model as three ways-

3 Opportunistically, achieves resource proficiency with reliable prediction on the regular workload seen most of the time achieves through local data center. Optimistically, response to high workload manages in rare time with the requirement of agile and responsive performance through cloud services. Deterministically, neglecting the response to sudden panic or oppressive workload dispose in rare time when the system is not agile to give 100 percent performance. For scheme s concreteness, we have to aimed design goals of workload factoring solutions included four: Reducing the higher workload and dynamic complexities in Regular State oriented application platform and avoiding overloading scenarios through Draining & Dispatching. Create Critical State oriented application platform enable through workload decomposition based on preliminary features of empirical threshold of system. Making rationale agile with resource managed Integrated Cloud Computing Model. Minimizing the data cache and replication overhead through Draining & Dispatching of selected requests for similar data objects into Critical State. A. Inspirational Logic View We give logical inspiration through fig.2 for ESRWF (Extreme State-Rank based Workload Factoring) scheme which has four basic components: System Mentor, State-Rank Distributor, Migration Controller and Resource & Workload Manager. The System Mentor updates the information of currently running system in case of workloads upon incoming requests and also keeps track of system performance and response to request of each data item. State-Rank Distributor distributes state-rank to each request as 0 (for Regular State) & 1 (for Critical State) to follow empirical threshold of empirical threshold indicator. Resource & Workload Manager Empirical Resource Estimator Threshold Indicator R System Mentor State-Rank Distributor 1 0 Migration Controller Ф, Drain 1, Cloud 0, LDC Figure 1. Inspirational Logic View of ESRWF with their elementary parts Resource & Workload Manager has two components these are Empirical Resource Estimator & Threshold Indicator may be say as primary & secondary component also respectively. The primary component checks the system state and estimates the request rate and request weight coefficient. This specifies the system performance & capacity, availability of resources and maximum loads that can be handled by system in Regular State. It may be set through previous information of system history that may be managed through predefined instructions with automatically or may be manually operated based on average records of previous Regular State which are used as resource provision decision. And secondary component of Resource & Workload Manager is based on empirical threshold of system is only and only applied to request has state-rank 1 in Critical State, it may be considered as anomalous entity so it redirect to cloud services otherwise drained for reliable & secure system from high unacceptable workload. After tagging state-rank and designation of threshold as 0, 1 in which 1 state-ranked request again ranked by Migration Controller for redirecting or draining. If it overhead the empirical threshold and MWL than it must be processed to drain with state-rank updated as φ. So, Migration Controller takes decision according to prerequisite conditions that which request type or rank type be redirecting to LDC or Cloud Services or Drained.

4 B. ESRATE Algorithm Now, we process algorithm ESRATE: Extreme State-Rank based Traffic Estimation which maintains two tables: Stateless Predecessor Table (SPT) and Count & State-Rank Table (CSRT). Given a request R, the algorithm outputs are Regular State processing if r will go to the Regular State with state-rank 0 otherwise Critical State Processing if it has state-rank 1 otherwise drained from this approach. It works as followed: Comparison Counter R Request + R R1 R2 Counting Data-ID Weight S-R Stateless Predecessor Table Filtering Figure 2. ESRATE Nidus View and Implementation of algorithm If the system is in Regular State, the CSRT (Count & State-Rank Table) is always set as Empty when first request R is arrived. If R matches any data item of CSRT (for asking same data) increase the counter of data item by 1 in counter column and update state-rank 0. If system is setting as Regular State after going Critical State then on basis of MWL (Maximal Workload Left) [10] [11], request is processed by LDC. Otherwise, randomly draw M requests from FIFO queue named as SPT (Stateless Predecessor Table) & compare them with R, if R matches any of the M request (for asking same data), pick that data item & put in CSRT with initialization of counter as 1 and state-rank 0 & update CSRT. If any request doesn t arrived again then system automatically dispose request from SPT, because there is no mean of that request to keep continue in SPT. At starting, if any data item requested at Critical State then it follow same procedure as when it is entered in Regular State. If data item of request R doesn t belong to CSRT then add R into SPT FIFO queue for request logs & returns. In Critical State, reset all counters to 0 and set state-rank 1 and calculating the request rate of each data item participated in CSRT. For each data item in CSRT, the request rate is its counter value divided by total requests arrives since entering the system in Critical State. Also, calculate estimated request rate correspond of each data item according to Section-V. If requests of data item cross or overhead the Empirical Threshold Indicator means workload so high not managed by system then request will be signified with state rank φ since draining it automatically. Otherwise redirect to cloud services on basis of LWL (Least Workload Left) [10] [11] as prerequisite Workload Factoring scheme with increment count by 1 and state-rank 1. The reason for the calculation of the request weight coefficient with request rate in cloud is that, the user feels request behavior inflicts two types of request rates: Peak Request Rate (20 videos per 6 seconds) which discriminates with less request weight coefficient & LWL basis to cloud services, other is Average Request Rate (20 videos per 60 seconds), the ARR is a long term rate while the PRR is a temporal rate have MWL be undertaken by LDC. IV. ANALYSIS A. Notation and Accuracy Requirement Matching Count and State-Rank Table

5 We assume that each request belongs one of data item. The rate of request denoted by and let = denote total request rate to system. Let = denote the proportion of request rate or actual request rate to the system that belongs to request. We have to design an efficient scheme to estimate for each. Since it is easy to measure, instead of directly estimating, we solve the equivalent problem of getting an estimate! of for each. Then we use! to estimate. We can view as the probability that an arriving requests belong to data item. We assume that is static or stationary over the time in which the estimation is done. We also assume that the probability that an arriving request belongs to a given data item is independent of all other requests. We can sample randomly in order to reduce this dependence. We now give the accuracy requirement for ESRATE will determine an estimated " such that-! # % 2, + % 2 ( *! # -% 2, + -% 2 ( * > With probability greater than / means we are willing to tolerate an error of % with probability less than / for all and an error of -% with probability less than / for all >. We consider that the proportion for most data item lies below some threshold proportion and we want the estimation to be accurate in the range [0, ]. Formally, we are given threshold proportion 0 1 and parameter - 1. A case, if there are data items with proportion greater than. The ESRATE will estimate with relative estimation error range of 3 4 5,16%. We use 7 8 =4.00 to denote the / percentile as Unit Normal Distribution, such as if / =99.9%. B. Main Result- as per follow complete process of [14] [19]. Lemma-1: Let ;(<,) represents the number of requests for data item after N request arrivals for ESRATE with = comparisons for each arrival. Then- Where, G 5 = I4JK L MN4O L(LPQR)S RTS U V <=?@ A(B,) BC D <[0,G 5 ] Proof: Follow the results of Lemma-5 from ESRATE [14] [19]. C. Minimum Sample Size Here Minimum Sample size is defined to be the number of request arrivals needed to perform the estimation. We may say the term estimation time and sample size interchangeably. CSRT serves as a filtering process on request which is entering in the SPT. We approach counting process when without using CSRT and that actively using the CSRT filtering process. Then, the minimum sample size of CSRT- D. Request Weight Coefficient < = W X L CY L (1) The heavy workload where there is no way to provide fairly service to high spikes having or bursty applications in the presence of oppressive users in Critical State. We have to provide dynamically decreasing weight of request through estimated coefficient for oppressive users to handle the fact that it is consolidates to assign static request weight accurately. This weight fixed according to request rate. It protects innocent users by discriminating oppressive users on heavy workload in Critical State. At processing dynamic request weight coefficient that reduces

6 g International Journal of Electronics and Computer Science Engineering Application Requests Local Data Center Runtime Server Extreme State- Rank Based Workload Factoring (ESRWF) State- Critical/Regular, Rank- 0/1/ф, X-100 % Resource Utilization HTTP Request HTTP Reply Empirical Threshold Dispatching Decision Decision Making rtsp://out_streamserver_ldc// Application Servers Rank- 0 Application Servers Yes or Rank- ф Tri-Way Trajectory rtsp://in_streamserver_noway// Simulations rtsp://in_streamserver_cloud// No, and Rank- 1 Cloud Services Application Servers Integrated Cloud Drain Resolver Application Servers. Shared Resource Platform (Cloud Infrastructure) Dedicated Application Platform (Local Data Center) Local Storage Open source RTP/RTSP Streaming Server With Heterogeneous, Hybrid & Community Cloud Cloud Storage Cloud Storage Cloud Storage Figure 3. Resource Management Scheme for Proposed Integrated Cloud Computing Model and Tri-Way Trajectory Simulation overview the weight assigned to oppressive users. For every request the mechanism counts the amount of traffic as total number of request and request rate with used memory. It uses this amount to affect the weight given to the innocent users. A time unit is set to roughly the expected burst time Z where ]^^ is average request rate. Let ^(_) be [\\ request rate measured in the requests is particular request s counter value divided by total requests arrives since entering the system in Critical State. Let ` be the amount of offered traffic during last sliding window. Request Weight coefficient, a() is- b, `+a()= N b c - d`e f, `.- Where, - b, Original Fixed Request Weight (by default set as 1). -- ^_.<, Threshold Request Rate or average request burst time. -` AB,, Previous Request Rate at time _, where ;<, is binomial function. BC -h, Reduction Factor, configure by system. We require that, h21 means h is greater, smaller the weight. With help of using request weight coefficient, we have to balancing load on basis of LWL and MWL with RR, WFQ or APFQ [11] like scheduling algorithm to transmit request to their particular state processing with following State-Rank. E. Speedup( ) Lemma-2: Given the accuracy requirement described above in Section-V and N be the number of request sample in CSRT is required for ESRATE- < ij\k,almnopqr W X L CY L (2)

7 Let us define the request rate amplification factor [16] for the rate change of data item before and after the Matching as- \ stuv \ wuxvu (3) Lemma-3: Given the accuracy requirement described in Section-V. < ij\k,almnopqr be the number of request samples required for ESRATE-CSRT(Matching) and < jkk,pymzpqr be the number of request samples required for ESRATE- SPT(Filtering). As well as < {\k,{lpqpqr be the number of request samples required for ESRATE-DRT (Draining). < jkk,pymzpqr = B }~, st ƒ L (4) < jkk,pymzpqr = B }~, st ƒ JB x vsƒ ƒ ˆ (5) As well as < k {lpqpqr be the number of request samples required for Draining.Therefore we have speedup of the detection (Matching, Filtering, and Draining) process even with Š _Œ on rate amplification factor due to historical information filtering. F. Memory Requirement Now we focus on the memory requirement for ESRATE. The memory requirement for the estimation scheme is proportional to the size of this subset of data items for which request rate and request weight coefficient are maintained. We therefore use the number of data items for which counts are maintained as surrogate for the memory requirement. So, we calculate the worst case expected memory requirement due to dependencies of comparisons. Given the request sample size N. In other words, we want to find an allocation of P that maximize the expected number of data item in CSRT- Lemma-4: Given the specified accuracy requirement for the maximum expected memory [14] in both states are- Proof: where, Ÿ = 4 œ7 8 5 =. ˆ Š_ ^ Š _Š_, [ (<)] 1.174@ X L ˆ Š_ š*_* Š _Š_, [ (<)] 1.174@ W X L œ7 8 5 = Y L L (6) [ (<)] X L 5d œ7 L 8 5 = (7) V. PERFORMANCE CRITERIA Through the evaluation, we target to answer a few questions arise from some technical misconception of Workload Factoring and traffic estimation over network through incoming requests for web services. A. Observation Tracery As observed analysis, dedicated runtime implementation of ESRWF scheme is developed through Tri-Way Trajectory Simulations as implemented part of proposed Integrated Cloud Computing Model described in fig.3 which may enhance the TestBed experiment of [16]. Yes, it is hard to obtain analytic results for the performance of ESRWF under a stochastic environment. To evaluate the behavior of ESRWF and efficiency of ESRATE in such an environment we use simulation results. We conduct the simulation tool using the CloudSim & GridSim-5.2 with network simulation tool OPNET Modeler 14.0 and for transmitting the request use the base line for applying the algorithm APFQ. Our simulation implementation includes the APFQ code without modifying it. The implementation collects the statistics for each data item every second (simulation time) in CSRT, sums up the offered traffic load of requests during a sliding window, and updates the request rate and request weight coefficient.

8 Available Online at ISSN (a) (b) Figure 4. (a) Customer viewed stream quality at both system states (b) Customer viewed stream quality at both system states on experimental setup- Tri-Way Trajectory Simulation Now for active tracery, we used the Yahoo! Video (India) [8], is 3 rd ranked online video website just after YouTube and MetaCafe in terms of total number of video views, uploading & downloading during January 2011, delivered totally 30.2 millions of video streams to million of unique Indian viewers [3]. It is 72% of the online population of India who take services of video streaming. We trace the Yahoo! Video site for 2 months (from January 11 to March 12, 2012), and the data was collected in every 30 minutes to 1 hour. Due to large scale of Yahoo! Video site, we limited the data collection to the first 10 pages of each category. Since each page contains 10 video objects, each time the measurement collects dynamic workload information for 1230 video files in total. Throughout the whole collection period, we recorded 2,843 unique videos which durations range from 2 to 6350 seconds and a total of 1,755,186 video views. This can be translated into a daily video request rate of There is nearly dissimilarity in statistics to calculate mean duration between sites. B. Requests Concurrency at servers Fig.4(b) shows the viewed stream quality from stream resources of Regular State (LDC Server) and stream resources of Critical State (Cloud Server) in the particular Workload Factoring experiment. For informal comparison, in this case both state servers have the typical configuration & proficiency. We observed that the concurrent connections went up; the Critical State server delivered more reliable streaming proficiency than the Regular State server. It could corroborate 175 concurrent stream connections whereas keeping the Customer-side proficiency at above 80, whereas the Regular State server could only corroborate around 87 average concurrent stream connections to keep the Customer-sided quality steadily at above 90. See fig.5(a), for allocated bandwidth for particular served requests. In the Tri-Way Trajectory Simulation we set the Regular State server capacity at 90 concurrent connections and that for Critical State servers at 170. Due to this Workload Factoring mechanism, we observed that the ratio of the maximum load to the average load was reduced to 1.94 in the Regular State and streaming proficiency at Critical State processing is 95% more than that in the Regular State processing. 1349

9 (a) (b) Figure 5. (a) Requests serve through ESRWF at both system states (b) Workload factoring performance: Memory Cost for ESRWF C. Minimizing Data Cache and Replication Overhead Linear approach of data accessing, prediction, servicing, caching, requesting and drain or dispatching through which our Workload Factoring scheme reduces data cache and replication overhead. It brings multiple and multitask benefits on author s model & have effective job & performance in Critical State. Yes, In Critical State data storage hierarchies & their levels of features based on ILMs be designed as a data cache. And disengage from Regular State through short extreme activated application of data accessing. Taking prediction of incoming requests for particular data item & their related request rate proportion through which system servicing with speeding up the dynamic provisioning process at LDC or runtime Server in Cloud; cached data can enlarge the capacity for particular runtime server for momentary relaxation. After applying drain or dispatching, only small sized request of data item will be requested. Also, apply WFQ-APFQ [11], Least Connections or RR type load balancing schemes [10] as well as make use of and derive benefit from content locality which based on High Workload based Dispatching. As a prior think is that to see fig.6(b), this technique leads only best resource planning & management appeal with comparison of IWF (Intelligent Workload Factoring) [16], which perform better in each case and may improve the quality of the IWF. D. Memory Cost & Predictions As comparison, unlike RATE [19], CATE [14] and Fast Top-k [16]; ESRATE is most accurate and fastest uses less memory to follow the request migration policy of Extreme State-Rank based Workload Factoring Scheme but addition of memory prediction estimation Ÿ at certain level due to system state through which scheme is more complicated and have desired high accuracy with sufficient ample stock of memory at Critical State. So, such dynamic tenancy of memory is effective runtime example of creation, storing & processing of memory block according to provisioning of incoming request. As fig.5(b) & fig.6(a), we also note that ESRATE use the typical amount of memory by the time they capture all medium-sized requests, which signifies that they need less memory size for estimation accuracy at both states.

10 (a) (b) Figure 6. (a) Desired Accuracy performed by ESRATE (b) Workload Handling Strategy managed by IWF & ESRWF E. Economical Tendency We give an ESRWF based application hosting solutions to host the measured Yahoo! Video stream load. In this solution, a local data center is over provisioned over regular workload (96.4%), and cloud based platform such as Amazon EC2 [1] is rented on high demand for critical workload (3.6%). It offers an economical solution for green Cloud Computing environment with 65-server oriented tiny local data center with 15-server oriented Drain Resolver and an annual rent for managing critical workload is approximately $42.56K only. As formality, we only include the server cost only though so many factors which influence the server cost had been neglected. We measure the application hosting solution for Yahoo! Video stream loads according to Methodology of [8]. Fig.4(a) shows the unique video requested by customer were viewed & served only 23 out of 5000 video streams in Critical State. TABLE I. PERFORMANCE CRITERIA OF ESRWF Hosting Platform Issues Unique Video Requested Equipment Required Annual Costs Requests Concurrency Solutions through ESRWF 23 unique video clips 65-server LDC + 15-Drain Resolver USD 42.56K approx. 90 at Regular & 175 at Critical State Ratio of max load to avg load 1.94 Resource Proficiency =95% Data Cache & Replication Overhead Minimized up to three orders of magnitude VI. CONCLUSIONS & FUTURE WORKS In this paper, we present the design of an Extreme State-Rank based Integrated Cloud Computing Model. For the future work, extending the Integrated Cloud Computing Model to stateful & provision based applications such as n-tier web services is a natural and challenging step. Many new problems arise such as session maintenance, service time estimation, and data consistency due to data dispatching in different states to process, fast data on demand service, integrating the dynamic web service scaling approach in our system; even there are many concepts missed for discussion such as load balancing schemes in states, data replication & consistency management in the Critical State, security management for an integrated cloud platform, and more. We have shown through both theoretical analyses of Observation Tracery and Tri-Way Trajectory Simulations that ESRATE is fast and memory-efficient. It estimates small data items very quickly and accurately, and still gives good estimation accuracy for large data items. Dependence within request arrivals may affect the estimation accuracy. Although the buffer-based approach can

11 alleviate the problem, a better approach that can further minimize the impact of dependence without additional overhead may be more preferable. We attempt to address this issue as part of future work also. With the proposed Workload Factoring technology and creating Drain Resolver Architecture & solutions, which gives the elastic natural environment for the green cloud infrastructure as means of resource planning, it develops a situation where cloud resources are used as supplementary extension of existing unable infrastructure to handle high workloads. It's not an all or nothing decision; companies can effort into the cloud without leaving permanently established infrastructure and applications. REFERENCES [1] Amazon web services, [2] Amazon, [3] ComScore Video Metrix report: India Viewers Watched an Average of 3 Hours of Online Video in July, Available: [4] Darwin streaming server, Available: [5] Google App Engine, [6] Openrtsp, Available: [7] Vmware cloud vservices, Available: [8] Yahoo! Video, [9] R. Pan, B. Prabhakar, and K. Psounis, Choke - a stateless active queue management scheme for approximating fair bandwidth allocation, in INFOCOM Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 2, 2000, pp Available: [10] A. Kumar, M. Sung, J. xu, and J. Wang, Data streaming algorithms for efficient and accurate estimation of flow distribution, in Proc. Of ACM SIGMETRICS, June 2004, to appear. [11] Anat Bremler-Barr, Nil Halachmi, Hanoch Levy, Aggressiveness protective Fair Queuing for Bursty Applications. Available: [12] Anthony T. Valte, Toby J. Valte, Robert Elsenpeter. Cloud Computing: A Practical Approach. Tata McGraw-Hill Edition 2010, 6 th Reprint. [13] Dr. Kumar Saurabh, Cloud Computing: Insights into New Era Infrastructure. WILEY-INDIA, First Edition [14] F. Hao, M. S. Kodialam, T. V. Lakshman, and H. Zhang, Fast, memory-efficient traffic estimation by coincidence counting. In INFOCOM, 2005, pp [15] G. Karypis and V. Kumar, Multilevel k-way hypergraph partitioning, in DAC 99: Proceedings of the 36th ACM/IEEE conference on Design automation. New York, NY, USA: ACM, 1999, pp [16] H. Zhang, G. Jiang, K. Yoshihira, H. Chen, and A. Saxena, Intelligent workload factoring for a hybrid Cloud Computing model, NEC Labs America Technical Report 2009-L036, Feb [17] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, Above the clouds: A berkeley view of cloud computing, EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS , Feb [Online]. Available: /TechRpts/2009/EECS html [18] M. Arregoces and M. Portolani, Data Center Fundamentals, Cisco Press, [19] M. Kodialam, T. V. Lakshman, and S. Mohanty, "Runs based Traffic Estimator (RATE): A simple, Memory Efficient Scheme for Per- Flow Rate Estimation", Proceedings of INFOCOM'2004.