بخشی از ترجمه فارسی
مقاله:
5.4 تطبیق منابع
دلیل اصلی اضافه نمودن محاسبات ابری از دیدگاه یک کاربر
جابجایی از یک مدل CAPEX به OPEX است که این کار به جای خریداری منابع فناوری
اطلاعات صورت می گیرد. در این راستا یک کمپانی به کمپانی دیگر برای منابع استفاده
شده پول پرداخت خواهد کرد. جنبه مهم این است که کمپانی به مدت طولانی نیازمند تبلیغ
منابع اش نخواد بود. امروزه این حالت معمول است زمانی که یک کمپانی منابع خود را در
یک شرکت سرمایه گذاری می کند و در نتیجه مقدار منابع توسعه یافته در زمان اوج به
حداکثر نخواهد رسید و یک روند منظم را طی می کند. مفهوم کلیدی چهارچوب بحث شده در
Zhuand Agrawal (2010) الگوریتم تطبیق پویای منابع است که مبتنی بر فرضیه کنترل
است. یک سیاست کنترل هدایت تقویت یادگیری برای تنظیم پارامترها تطبیق داده می شود
به طوری که سود برنامه با استفاده از سربار به حداکثر برسد. چنین مدل کنترلی می
تواند سریع و با دقت اموزش داده شود. علاوه بر این یک مدل منبع برای نگاشت هر
ترکیبی از مقادیر از پارامترهای تطبیقی با ملزوم ساختن منبع صورت می گیرد تا تضمین
نماید هزینه از بودجه موجود تجاوز نکند.
Duong et al (2009) یک چهارچوب انعطاف
پذیر را برای ارائه منابع پویا و تطبیق در ابرهای IaaS مطرح کردند. هسته این
چهارچوب تنظیم الگوریتم های تطبیقی منابع است که بار کاری را با اطلاعات منبع
کاربردی ساخته تا تغییرات تصمیات رادر تغییر تقاضای کاربران پوشش دهد.
Senna et
al (2011) یک معماری برای مدیریت و تطبیق شبکه های مجازی بر ابر ارائه دادند.
زیرساخت آن ها اجازه ساخت شبکه های مجازی مرتبط با اجرای جریان های کاری را داده و
از محیط کاربر حفاظت می کند. شبکه های مجازی استفاده شده در اجرای جریان کاری دارای
عملکرد نظارت شده اشان توسط مدیری هستند که نقش پیش گیرانه ای در مورد خرابی عملکرد
در زمان الزامات را دارد.
انعطاف پذیری تطبیق راه حل های ابر را برای تمامی
کاربران صورت می بخشد تا اطمینان دهد ان ها آن چه را که دقیق می خواهند را دریافت
کرده اند. بدین وسیله محاسبه ابری نه تنها راه جدیدی از چگونگی اجرای محاسبات را
صورت می بخشند بلکه طیفی از مسائل ICT شناخته شده را در مناطق مختلف آموزش و بهداشت
و درمان و… حل می کنند.تطبیق منبع میزبان های مجازی باید به طور پویا برای تقاضاهای
به روز شده به خوبی برنامه های collocate حل شود تا صرفه جویی در مصرف انرژی صورت
پذیرد. Sclater (2011). از مهم تر تراکنش های منبع ، در طول حجم کار است که باید با
توجه به عدم تطابق منابع پیشنهادی به حداقل رسانده شود. یک سیستم که می تواند به
طور خودکار مقیاس بندی منابع زیرساختی به اشتراک گذاشته را صورت بخشد در
Charalambous (2010) انجام شده است. نظارت های مدیر تطبیق و تخصیص خودکار منابع به
کاربران از طریقی پویا صورت می گیرد. با این حال این شیوه متمرکز نمی تواند در
آینده متناسب با محیط ابری چند ارائه دهنده باشد. زیرا ارائه دهندگان مختلف ممکن
نیست بخواهند توسط چنین مدیریت متمرکزی نظارت شوند. درجه مدیریت منابع ، پیوند
منابع API و هماهنگی منابع در چندین ابر در روشی بی نقص صورت گرفته و اهداف عملکردی
را حفظ می کند که می تواند بسیار شایسته رسیدگی در آینده باشد. همچنین مقیاس بندی
پویای LBS و تاثیراتش بر مقیاس بندی کل برنامه در
Vaquero et al (2011) و سرویس
مقیاس بندی خودکار آمازون مطرح شده است. هدف نویسندگان در Baldine et al (2009)
مدیریت شبکه اساسی به صورت منابع کلاس اولی است که می تواند زمان بندی و تخصیص
همکار گونه را با منابع محاسباتی و ذخیره سازی صورت بخشد تا یک شبکه کامل اماده به
ساخت را معرفی نماید.
Jung et al (2008) یک شیوه ترکیبی جدید برای رفتاری خودکار
پیشنهاد کردند که از مدل های نظریه صف بندی با تکنیک های بهینه سازی استفاده می کند
تا رفتار مدل را پیش بینی کرده و به طور خودکار تنظیمات بهینه سیستم را تولید کند.
Marshall) 2010 ) مدیریت منابع را اجرا کرده و بر Nimbus toolkit ساخته شدند و به
صورت امن و پویا خوشه های فیزیکی را بر ابر ارائه کردند. رابط های مدیریت الاستیک
به طور مستقیم با مدیران محلی در ارتبط اند همانند Torque .
Raghavan et al
(2009). طراحی و پیاده سازی محدوده نرخ توزیع شده را با همکاری “نر” کلی تجمیع در
گوشه های متفاوت مطرح ساخته و سیاست های ترافیک شبکه مبتنی بر ابر را با ان در
همکاری قرار داد و همچنان اطمینان داد که جریان های لایه پاسخ ازدحام رفتار جریان
گونه ای خواهند داشت اگر به اشتراک گذاشته شوند.
5.4.1 چالش های حل نشده تطبیق
منابع
– تقاضا برای استفاده از سرویس های ابر ارائه شده توسط فروشنده چگونه است؟
آیا این امر ثابت است یا به طور گسترده متغیر است؟
– فرکانس استفاده از منابع
ابر چیست؟ مکررا تکرار می شود؟ استفاده مکرر در حقیقت مدل پرداخت پس از برداشت را
اقتصادی ترمی کند؟ آیا سرویس های سفارشی سازی شده توسط فروشندگان نیازاند؟
فروشندگان ابر سرویس های سفارشی سازی شده را بیشتر ارائه می کنند و به همین ترتیب
قیمت کاری آنها جذاب به نظر نمی رسد.
– آیا ماموریت برنامه مهم است؟ یک ماموریت
بحرانی آیا نیازمند قدرت SLAs است که نتواند قادر به رفع نیاز ها نباشد؟
– آیا
یک مسئله می تواند در قطعه ای برنامه ما رخ دهد که QoE تحت تاثیر انطباق قرار گیرد
یا خیر؟
– آیا مسئله اطلاعات یا ما ارائه دهنده سرویس برنامه ما به اشتراک
گذاشته خواهد شد اگر برنامه ما نتواند بطور خودکا خود را کنترل کند؟
– آیا می
توان تمام جزئیات فعال و غیر فعال را در اتصال و مسیر انتها به انتها و سطوح دامنه
ISP نظارت کنیم؟
– می توان تمام اندازه گیری های مربوط به ارائه آفلاین کاربران
QoE را تحلیل نمود؟ برای نمونه شناسایی در زمان وقایع غیرعادی تاثیر گذار بر
کاربران QoE .
بخشی از مقاله
انگلیسی:
5.4. Resource adaptation
The primary reason for adapting cloud
computing from a user perspective is to move from the model of capital
expenditure (CAPEX) to operational expenditure(OPEX). Instead of buying IT
resources like machines, storage devices etc. and employing personnel for
operating, maintaining etc., a company pays another company (the provider) for
the actual resources used (pay-as-you-go). An important aspect of this is that a
company no longer needs to overprovision its IT resources. It is typical today,
when a company invests in its own resources, that the amount of resources
invested in corresponds to the maximum amount of resources needed at peak times
with the result that much of these resources are not needed at all during
regular periods. The key conceptual component of framework discussed in Zhu and
Agrawal (2010) is a dynamic resource adaptation algorithm, which is based on
control theory. A reinforcement learning guided control policy is applied to
adjust the adaptive parameters so that application benefit is maximized within
the time constraint using modest overhead. Such a control model can be trained
fast and accurately. Furthermore, a resource model is proposed to map any given
combination of values of adaptive parameters to resource requirements in order
to guarantee that the resource cost stays under the budget. Duong et al. (2009)
have proposed an extensible framework for dynamic resource provisioning and
adaptation in IaaS clouds. The core of this framework is a set of resource
adaptation algorithms which utilize workload and resource information to
make informed provisioning decisions in light of dynamically changing users
demands. Jung et al. (2010) present Mistral, a holistic optimization system that
balances power consumption, application performance, and transient
power/performance costs due to adaptation actions and decision making in a
single unified framework. By doing so, it can dynamically choose from a variety
of actions with differing effects in a multiple application, and dynamic
workload environment. Calyam et al. (2011) use OnTimeMeasure-enabled performance
intelligence to compare utility-driven resource allocation schemes in virtual
desktop clouds. The results from the global environment for network
innovations(GENI) infrastructure experiments carried out by the authors
demonstrated how performance intelligence enables autonomic nature of FI (Future
Internet) applications to mitigate the costly resource overprovisioning and user
QoE (Quality of Experience) guesswork, which are common in the current Internet.
Senna et al. (2011) present an architecture for management and adaptation of
virtual networks on clouds. Their infrastructure allows the creation of virtual
networks on demand, associated with the execution of workflows, isolating and
protecting the user environment. The virtual networks used in workflow execution
has its performance monitored by the manager which acts preemptively in the case
of performance dropping below stated requirements. Flexibility enables the
adaptation of cloud solutions to all users to ensure that they get exactly what
they want and need. By that, cloud computing not only introduces a new way of
how to perform computations over the Internet, but some observers also observed
that it holds the potential to solve a range of ICT (information and
communications technology) problems identi- fied within disparate areas such as
education, healthcare, climate change, terrorism, economics etc. as per Schubert
(2010). Resource adaptation of the virtual hosts should dynamically scale to the
updated demands (cloud computing) as well as colocate applications to save on
energy consumption (green computing) as per Sclater (2011). Most importantly,
resource transitions during workload surges should occur while minimizing the
expected loss due to mismatches of the resource predictions and actual workload
demands. A system that can automatically scale its share of infrastructure
resources is designed in Charalambous (2010). The adaptation manager monitors
and autonomically allocates resources to users in a dynamic way. However, this
centralized approach cannot fit in the future multiprovider cloud environment,
since different providers may not want to be controlled by such a centralized
manager. There have been great advances towards automatically managing
collections of inter-related and context-dependent VMs (i.e. a service) in a
holistic manner by using policies and rules. The degree of resource management,
the bonding to the underlying API and coordinating resources spread across
several clouds in a seamless manner while maintaining the performance objectives
are major concerns that deserve further study. Also, dynamically scaling LBS
(location based services) and its effects on whole application scalability are
reported in Vaquero et al. (2011) and Amazon auto scaling service. The goal of
authors in Baldine et al. (2009) is to manage the network substrate as a
first-class resource that can be co-scheduled and co-allocated along with
compute and storage resources, to instantiate a complete built-to-order network
slice hosting a guest application, service, network experiment, or software
environment. The networked cloud hosting substrate can incorporate network
resources from multiple transit providers and server hosting or other resources
from multiple edge sites (a multi-domain substrate). Jung et al. (2008) propose
a novel hybrid approach for enabling autonomic behavior that uses queuing
theoretic models along with optimization techniques to predict system behavior
and automatically generate optimal system configurations. Marshall et al. (2010)
have implemented a resource manager, built on the Nimbus toolkit to dynamically
and securely extend existing physical clusters into the cloud. The elastic site
manager interfaces directly with local resource managers, such as Torque.
Raghavan et al. (2009) present the design and implementation of distributed rate
limiters, which work together to enforce a global rate limit across traffic
aggregates at multiple sites, enabling the coordinated policing of a cloud-based
service network traffic. This abstraction not only enforces a global limit, but
also ensures that congestion-responsive transport-layer flows behave as if they
traversed a single, shared limiter. Table 10 summarizes some of the resource
adaptation schemes. Table 11 lists out the performance metrics of the resource
adaptation schemes.
5.4.1. Open challenges in resource
adaptation How is the demand for using the cloud services provided by the
vendor? Is it mostly constant or widely varying? What is the frequency of usage
of cloud resources? Is it highly frequent? Very frequent usage in fact makes
less economic sense to go for cloud based pay-as-you-go model. Do we need highly
customized services/API (application programming interfaces) to be exposed by
the vendor? Cloud vendors would not find it economically attractive to provide
highly customized services and hence price for enterprise (users of cloud) might
also be not very attractive. Is the application mission critical? A mission
critical application would need very stringent SLAs, which cloud vendors could
not be able to satisfy as yet. An industry or application with highly stringent
compliance requirements might still not find it suitable to consume key services
from a vendor due to inherent risks involved. Can a problem occurence in our
slice environment that impacts our QoE be identified and notified to our
application to adapt and heal? Can problem information also be shared with us
and our application service provider if our application cannot automatically
heal itself? Can we monitor all the detailed active (e.g., Ping, traceroute,
iperf) and passive (e.g., TCP dump, netow, router-interface statistics)
measurements at end-to-end hop, link, path and slice levels across multiple
federated ISP domains? Can we analyze all the measurements to offline provision
adequate resources to deliver satisfactory user QoE, and online i.e., real-time
identify anomalous events impacting user QoE?
