دانلود رایگان مقاله بررسی قابلیت ارتجاعی ابر

چکیده

           قابلیت ارتجاعی ابر ویژگی منحصر به فرد محیط‍‍‍‌های ابری است که تأمین (کاهش تأمین) تقاضا و یا تنظیم مجدد منابع توسعه ابر را می‌پذیرد. مدیریت کارایی قابلیت ارتجاعی ابر چالشی است که توجه جامعه پژوهشی را به خود جلب کرده است. این کار به منزله بررسی تلاش‌های پژوهشی در این راستا است. سهم اصلی این کار، مرور دقیق آخرین روش‌های مدیریت ارتجاعی و ارائه طرح دقیق طبقه‌بندی با تمرکز بر روش‌های تصمیم‌گیری ارتجاعی است. در پایان، درباره چالش‌های تحقیقاتی مختلف و جهت‌های تحقیقاتی بیشتر درباره کلیه مراحل قابلیت ارتجاعی بحث می‌کنیم که می‌توان به عنوان حالت خاص رفتار ارادی سیستم‌های محاسباتی تلقی کرد (این تحقیق با همکاری اتحادیه اروپا (صندوق اجتماعی اروپا- ESF) و صندوق‌های ملی یونان از طریق برنامه عملیاتی «آموزش و یادگیری بلند مدت چارچوب مرجع استراتژیک ملی (NSRF)- برنامه سرمایه‌گذاری تحقیقاتی: تالس . سرمایه‌گذاری در جامعه دانش از طریق صندوق اجتماعی اروپا» انجام شده است).

1. مقدمه

         محاسبات ابر مدل توسعه‌ای را ارائه می‌دهد که هدفش کاهش هزینه‌های لحظه‌ای منابع محاسباتی از طریق تنظیم اجاره منابع مجازی پویا است که می‌تواند بر پایه تقاضا تشکیل شود. منابع مجازی نسخه‌های مجازی دنیای واقعی هستند، اغلب به صورت ماشین‌های مجازی (VMs) هستند که از تکنولوژی‌های مجازی‌سازی استفاده می‌کنند [65]. مدل پیشنهادی پرداخت بهای خرید با مدیریت منابع انعطاف‌پذیر به پذیرش وسیع در زمینه استفاده از ابر کمک کرده است، زیرا مشتری موظف است تنها برای منابع مورد استفاده بهایی پرداخت کند. بدین ترتیب، محاسبات ابری نه تنها قادر به ارائه منابع محاسباتی از راه دور (به عنوان مثال، ماشین‌های مجازی) گزینه‌های اصلی برای مؤسسات علمی هستند بلکه قادر به ارائه منابع در هر اندازه‌ای از سازمان‌ها و شرکت‌ها هستند. با این وجود، مدیریت منابع کارا جنبه کلیدی برای کاهش هزینه توسعه است.

         کارهای متعددی وجود دارند که روش‌های مختلف مکانیزم ارتجاعی را ارائه می‌دهند. در این مقاله تمرکزمان بر تمامی جنبه‌های ارتجاعی است اما به طور خاص قصد داریم که در رابطه با مدل‌های پایه‌ای، مکانیزم تصمیم‌گیری را مورد استفاده قرار دهیم. علاوه بر این، قصد داریم از طریق طبقه‌بندی‌مان روش‌های مختلفی را توسعه داده و مقایسه کنیم که امروزه تمایل به توسعه در انزوا دارند.

         روش‌های ارتجاعی را به عنوان موضوعات بین رشته‌ای دو حوزه اصلی رایانه‌ای توزیع‌ شده/ ابر و محاسبات ارادی می‌سنجیم. همانند حوزه محاسبات ارادی، شامل 4 مرحله حلقه MAPE است [44]، یعنی، نظارت، تحلیل، برنامه‌ریزی و اجرا. هر مرحله متمایز، چالش‌های تحقیقی منحصر به فردی را ارائه می‌دهد که در آثار ارائه شده با روش‌های مختلف مورد توجه قرار گرفته است. در این مقاله، بیشتر بر سه مرحله آخر متمرکز می‌شویم.

         برخی از تلاش‌ها در گذشته برای ایجاد دید کلی در حوزه ارتجاعی صورت گرفته است، به عنوان مثال، [26] مکمل کار ماست، اما بیشتر بر ابزارها، معیارها و حجم کار متمرکز است.  راهبردهای ارتجاعی را به طور گسترده‌تر به عنوان مکانیزم تصمیم‌گیری ارتجاعی شرح می‌دهیم. [48] نیز مکمل کار ماست، اما پیشنهادات جدیدتری ارائه می‌دهیم و طیف گسترده‌ای از اقدامات و اهداف ارتجاعی را پوشش می‌دهیم. بررسی قدیمی‌تر و محدودتری در [33] انجام شده است. بررسی کلی سیستماتیک درباره خدمات تجاری ابر در [46] انجام شده است، که در آن نویسندگان چالش اصلی درباره ویژگی ارتجاعی را مطرح کرده‌اند. همچنین، کار ما شکاف مهم درباره این مسأله را پر می‌کند.

         ساختار این مقاله بررسی به شرح زیر است. در بخش 2، دسته‌بندی و جدول طبقه‌‌بندی را ارائه می‌دهیم. در بخش 3، جزئیات بیشتری درباره هر بعد از طبقه‌بندی‌مان ارائه می‌دهیم و یافته‌های اصلی را به تصویر می‌کشیم. در فصل 4 نتیجه‌گیری را ارائه می‌دهیم.

2. دسته‌بندی و طبقه‌‌بندی

         به منظور ارائه طبقه‌بندی مختصر روش‌های موجود برای ارتجاع ابر، ابتدا طبقه‌بندی ارائه می‌دهیم که ما را قادر می‌سازد تا جنبه‌های متمایز پیشنهادات مختلف را روشن کنیم. طبقه‌بندی در شکل 1 خلاصه شده و شامل ابعاد زیر است:

- محدوده. این جنبه به دو دسته طبقه‌بندی می‌شود: (1) برقرار کننده و (2) نوع کاربرد. اولی نشان می‌دهد که آیا روش ارتجاعی توسط ارائه دهنده زیرساخت ابر (ارائه دهنده ابر (CP)) اعمال می‌شود یا توسط کاربر زیرساخت ابر اعمال می‌شود که مدیریت برنامه‌های ابر را در بالای زیرساخت ابر (ارائه دهنده سرویس (SP)) اعمال می‌کند. نوع کاربرد نشان می‌دهد که پیشنهاد به مدیریت ارتجاعی نوع خاصی از کاربر ابر در لیست زیر اشاره دارد: پایگاده داده‌های ارتباطی (DBs)، پایگاه داده‌های NoSQL (NoSQL DBs)، برنامه‌های چندلایه (به عنوان مثال، برنامه‌های کاربردی وب خاص)، Generic (در صورتی که ابزار برنامه کاربردی- غیرارادی) و یا ذخیره‌سازی.

- هدف. در این بعد، روش‌ها را طبق هدف اقدامات ارتجاعی دسته‌بندی می‌کنیم. هدف می‌تواند یکی از موارد زیر باشد: (1) عملکرد، (2) دسترسی، (3) هزینه، (4) انرژی. عملکرد مربوط به تعمیر و حفظ یا تضمین قابل قبول کاربرد و یا توافق سطح خدمات (SLA) مشخص شده عملکرد نرم‌افزار است. در دسترس بودن به درجه‌ای اشاره دارد که در آن برنامه‌ها و منابع در زمان قابل اجرا بوده و در زمان مورد نیاز کاربر نهایی قابل اعتماد باشند [42]. هزینه به کاهش هزینه‌های عملیاتی برنامه‌های توسعه‌یافته در ابر اشاره دارد که عموماً هدف عملکرد را نیز حفظ می‌کنند و یا آستانه هزینه‌ها را در محدودیت‌های عملکرد خاص نگه می‌دارند. در پایان، طبقه‌بندی انرژی، به طور دقیق مربوط به هزینه است اما شامل روش‌های ارتجاعی نیز می‌باشد که به طور مستقیم در به حداقل رساندن میزان انرژی کمک می‌کنند.

- تصمیم‌گیری. چهار معیار دسته‌بندی متمایز وجود دارد که روش تصمیم‌گیری هر کار را در طبقه‌بندی ما مشخص می‌کند، یعنی (1) قابلیت اطمینان، که نشان دهنده آن است که آیا مکانیزیم ارتجاعی در روش واکنش‌پذیر یا پیشگیرانه ایجاد می‌شود یا خیر؛ (2) مکانیسم که به روش تصمیم‌گیری اشاره دارد؛ (3) مدل پیش‌بینی (PM) که نشان دهنده استفاده از مدلی برای پیش‌بینی تغییرات بار ورودی آینده و یا ارزش‌های ارزیابی خاص است؛ و (4) مدل سیستم (SM) که به استفاده از مدل برای نشان دادن رفتار (ارتجاعی) سیستم اشاره دارد که در آن سیستم به طور کاملاً ارتجاعی (مانند، صف) ساخته شده است. مکانیزم‌های انعطاف‌پذیر بیشتر به دسته‌های زیر طبقه‌بندی می‌شوند: (1) مبتنی بر قانون، (2) بهینه‌سازی ریاضی/ آماری، (3) یادگیری ماشین، (4) نظریه کنترل و (5) بررسی مدل با توجه به زمینه اصلی که متعلق به سیاست ارتجاعی است.

- عمل ارتجاعی. قابلیت ارتجاعی منبع ابر را می‌توان در فرم‌های مختلف اعمال کرد و مربوط به تغییرات در (1) اندازه (مقیاس عمودی (VS))، (2) مکان (تغییر مکان در ماشین‌های مجازی (VMLM)) یا (3) تعداد ماشین‌های مجازی به کار رفته (مقیاس افقی (HS)) است. مثال‌هایی از این نوع قابلیت ارتجاع به ترتیب عبارتند از تخصیص حافظه بیشتر یا CPU برای ماشین‌های مجازی، حرکت ماشین‌های مجازی به سوی ماشین فیزیکی کمتر بارگذاری شده و افزایش تعداد ماشین‌های مجازی خوشه برنامه. علاوه بر این، عمل ارتجاعی شامل دو نوع ارتجاع دیگر است، (4) پیکربندی مجدد برنامه (AR)، که در آن ابزار الاستیک قادر به تغییر جبنه‌های کاربردی خاص هستند (به عنوان مثال، اندازه دریافت پایگاده داده‌های ارتباطی) و (5) تغییر مکان برنامه کاربردی (ALM) که در آن اجزای کاربرد خاص در ماشین‌های مجازی مانند پایگاده داده‌ تغییر مکان می‌دهند.

- ارائه دهنده. این طبقه‌بندی به دسته‌بندی تعداد ارائه‌دهندگان زیرساخت ابر اشاره دارد که به طور همزمان از ابزار ارتجاعی پشتیبانی می‌کنند. مقادیر احتمالی (1) منفرد، که تنها نشان‌دهنده پشتیبانی از ارائه دهنده ابر است، (2) منفرد*، که نشان‌دهنده پشتیبانی از بیش از یک ارائه دهنده است، با وجود آن که همزمان نیستند، و (3) چندگانه، که در آن کنترل ارتجاع ارائه‌دهندگان ابر چندگانه را به طور همزمان گسترش می‌دهد.

- ارزیابی. در پایان، آخرین جنبه به نوع ارزیابی هر کار اشاره دارد. مقادیر احتمالی عبارتند از: (1) شبیه‌سازی، که در آن نتایج بر پایه محاسبات در محیط مصنوعی شبیه‌سازی‌شده بدست می‌آید (به عنوان مثال، OMNeT++)، (2) واقعی، که در آن ابزار ارتجاعی بر پایه زیرساخت حقیقی ابر مورد استفاده قرار می‌گیرند.

         بر پایه طبقه‌بندی بالا، پیشنهادات موجود برای ارتجاع ابر در جدول 1 ارائه شده است. طبقه‌بندی بالا نوع اطلاعات بازخورد جمع‌آوری‌شده توسط محیط را برای اجرای تصمیم‌گیری و اجرای ارتجاع پوشش نمی‌دهند، زیرا به نظر می‌رسد نوع بازخورد نقش کمتری در طبقه‌بندی پیشنهادات بازی می‌کند. به طور خاص، تمام پیشنهادات برای کمک به تصمیم‌گیری از یک مکانیزم برای نظارت بر معیارهای خاص سیستم/ شبکه/ نرم‌افزار استفاده می‌کنند. برای مقابله با خوشه بار احتمالی یا ناپایداری‌های ارزیابی، از بسیاری از آثار روش‌های هموارسازی مانند میانگین حرکت وزن دار نمایی (EWMA)، میانگین حرکت نمایی (EMA) و یا میانگین حرکت (MA)، استفاده می‌شود. جزئیات بیشتر به علت محدودیت فضا حذف شده است.

Abstract

          Cloud elasticity is a unique feature of cloud environments, which allows for the on demand (de-)provisioning or reconfiguration of the resources of cloud deployments. The efficient handling of cloud elasticity is a challenge that attracts the interest of the research community. This work constitutes a survey of research efforts towards this direction. The main contribution of this work is an up-to-date review of the latest elasticity handling approaches and a detailed classification scheme, focusing on the elasticity decision making techniques. Finally, we discuss various research challenges and directions of further research, regarding all phases of cloud elasticity, which can be deemed as a special case of autonomic behavior of computing systems (This research has been co-financed by the European Union (European Social Fund - ESF) and Greek national funds through the Operational Program “Education and Lifelong Learning of the National Strategic Reference Framework (NSRF) - Research Funding Program: Thales. Investing in knowledge society through the European Social Fund.

1 Introduction

         Cloud computing forms a deployment model, which aims to reduce the momentary cost of the computing resources through the leasing of dynamically adjusted virtual resources, which can be occupied on-demand. Virtual resources are virtual versions of actual resources, most commonly in the form of Virtual Machines (VMs), which leverage the virtualization technology [65]. The offered pay-as-yougo pricing model accompanied by the elastic resource handling, has assisted the wide adoption of the cloud deployments, as the client is obliged to pay only for the used resource. As such, cloud computing has managed to make the provision of remote computing resources (e.g., VMs) the main option not only for scientific institutions but any size of organizations and enterprises. However, the efficient resource handling is a key aspect to the deployment cost reduction.

         There are numerous works that propose various cloud elasticity handling mechanisms. In this work, our focus is on all aspects of elasticity, but we particularly aim to shed light on the decision making mechanisms in relation with the underlying models employed. Additionally, through our taxonomy, we aim to render the various techniques, which nowadays tend to be developed in isolation, more comparable with each other.

       We regard elasticity techniques as an interdisciplinary field of two main areas: distributed/cloud computing and autonomic computing. As a field of autonomic computing, it comprises all four phases of the MAPE loop [44], namely Monitoring, Analysis, Planning and Execution. Each distinct phase presents unique research challenges, which are addressed by the presented works with various approaches. In this work, we mostly focus on the last three phases.

        Some efforts to create an overview of the cloud elasticity area have been made in the past, for example [26] is complementary to our work, but it focuses more on the tools, the benchmarks and the workloads. We present elasticity strategies in a more broader fashion as we elaborate more on the elasticity decision mechanism. [48] is also complementary to our work, but we present more up-to-date proposals and cover a more extended range of elasticity actions and objectives. An older and narrower survey has also appeared in [33]. A general systematic review about commercial cloud services is conducted in [46], where the authors present the main challenges regarding the elasticity property. As such, our work fills an important gap on a timely issue.

         The structure of this survey paper is as follows. In Sect. 2, we present the taxonomy and the classification table. In Sect. 3, we delve into more details for each classification dimension of our taxonomy and we outline the main findings. We conclude in Sect.

2 Taxonomy and Classification

         In order to provide a concise classification of the existing approaches to cloud elasticity, we first propose a taxonomy that will enable our work to shed light on the differentiating aspects of the various proposals. The taxonomy is summarized in Fig. 1 and consists of the following dimensions:

– Scope. This aspect is divided into two classification categories (i) the Enactor and the (ii) Application Type. The former indicates whether the elastic technique is applied by the cloud infrastructure provider (Cloud Provider (CP)) or the user of the cloud infrastructure, who deploys and manages cloud applications on top of the cloud infrastructure (Service Provider (SP)). Application Type indicates whether the proposal refers to the elastic handling of a particular type of cloud application from the following list: relational databases (DBs), NoSQL databases (NoSQL DBs), Multi-tier Applications (e.g., typical business web applications), Generic (if the tool is application-agnostic) or Storage.

– Purpose. In this dimension, we classify the techniques according to the purpose of elasticity actions. The purpose can be one of the following: (i) Performance, (ii) Availability, (iii) Cost, (iv) Energy. Performance, refers to the maintenance or guarantee of acceptable, either user or Service Level Agreement (SLA) specified, application performance. Availability refers to the degree to which applications and resources are in an operable and committable state at the time point when they are needed by end users [42]. Cost refers either to the reduction of the operational cost of the application deployed in the cloud, commonly also maintaining the Performance goal, or to the maintenance of cost thresholds under specific performance constraints. Finally, the Energy category, is closely related to the Cost one but covers elastic techniques, which directly aim at minimizing the energy footprint.

– Decision Making. There are four distinct categorization criteria that characterize the decision making procedure of every work in our taxonomy, namely (i) Trigger, which indicates whether the elasticity mechanism is triggered in a reactive or proactive manner; (ii) Mechanism, which refers to the decision making methodology; (iii) Prediction Model (PM), which denotes the utilization of a model to predict future incoming load variations or specific measurement values; and (iv) System Model (SM), which refers to the utilization of a model to represent the (elastic) behavior of the system, on top of which the complete elasticity policy is built (e.g., queues). Elasticity mechanisms are further classified into the following categories: (1) Rule Based, (2) Mathematical/Statistical Optimization, (3) Machine Learning, (4) Control Theory and (5) Model Checking according to the main field to which the elasticity policy belongs.

– Elastic Action. Cloud resource elasticity may be applied in different forms and can refer to modifications in (i) the size (Vertical Scaling (VS)), (ii) the location (VM Live Migration (VMLM)) or (iii) the number of VMs employed (Horizontal Scaling (HS)). Examples of these three elasticity types are the allocation of more memory or CPU to a VM, moving a VM to a less loaded physical machine and increasing the number of VMs of an application cluster, respectively. Elastic Action additionally includes two other elasticity types, (iv) the Application Reconfiguration (AR), where the elastic tool is capable of handling specific application aspects (e.g., DB cache size) and (v) Application Live Migration (ALM), where only application-specific components are migrated instead of the full VM, such as database instances.

– Provider. This classification category refers to the number of cloud infrastructure providers that the elastic tool supports simultaneously. The possible values are (i) Single, which denote that only one cloud provider is supported, (ii) Single*, which denotes that more than one providers are supported, however not simultaneously and (iii) multiple, where the elasticity control is spread across multiple cloud providers simultaneously.

– Evaluation. Finally, the last aspect refers to the type of the Evaluation of every work. The possible values are: (i) Simulation, where the results are obtained based on computations on a simulated artificial environment (e.g., OMNeT++), (ii) Emulation where the evaluations results are obtained in an artificial environment that behaves according to real-world traces, and (iii) Real, where the elastic tool is applied on a real cloud infrastructure.

          Based on the taxonomy above, we classify the existing proposals for cloud elasticity as shown in Table 1. The taxonomy above does not cover the type of the feedback information collected by the environment to drive the elasticity decision making and enforcement, because the type of the feedback seems to play a less important role in classifying the proposals. More specifically, all proposals utilize a mechanism to monitor specific system/network/application-specific metrics to assist the decision making. To deal with possible load spikes or measurement instabilities, many works utilize smoothing techniques like Exponential Weighted Moving Average (EWMA), Exponential Moving Average (EMA) or just Moving Average (MA). Further details are omitted due to space constraints.

چکیده

1. مقدمه

2. دسته‌بندی و طبقه‌‌بندی

3. خلاصه روش‌های موجود

3.1. محدوده

3.2. هدف

3.3. تصمیم‌گیری

3.4. عمل ارتجاعی

3.5. ارائه‌دهنده

3.6. ارزیابی

3.7. بررسی و چالش‌های تحقیقاتی

4. خلاصه

منابع

Abstract

1 Introduction

2 Taxonomy and Classification

3 Overview of Existing Solutions

3.1 Scope

3.2 Purpose

3.3 Decision Making

3.4 Elastic Action

3.5 Provider

3.6 Evaluation

3.7 Discussion and Research Challenges

4 Summary

References