دانلود رایگان ترجمه مقاله رفتار کشسانی سرویس ابری (اسپرینگر ۲۰۱۴)

مبتدی (مناسب برای درک مفهوم کلی مطلب) (ترجمه به صورت ناقص انجام شده است)

اطلاعات کشش، از متریک های کشش، الزامات کشش، و قابلیت های کشش تشکیل شده است که هر کدام از آن ها به منابع مختلف زیرساخت ها یا بخش های سرویس مرتبط هستند. قابلیت های کشش با هم به عنوان فرایندهای کنترل کشش ((ECPs دسته بندی می شوند همانطور كه در بخش بعدی شرح داده می شوند، و رفتارهای خاص كشش را بر بخش های مختلف سرویس تحمیل می كنند كه آن را به عنوان رفتارهای بخش سرویس مدل می كنیم. رفتارهای بخش سرویس را مدل می کنیم، زیرا کنترل کننده ها باید تأثیر اجرای ECP در سطوح مختلف را تعیین کنند (به عنوان مثال قبل از اینکه گره پایگاه داده جدیدی تخصیص دهیم، تاثیر در توپولوژی سرویس پایگاه داده و در کل سطح سرویس ابری باید تعیین شود ). به طور مفهومی، رفتار بخش سرویس به عنوان رفتار SPi برای یک SPi خاص در یک دوره تعریف شده از زمان [شروع، پایان] با تمام متریک هایMaS Pi نشان داده می شود کهSPi را نظارت می کند. بنابراین، رفتار یک سرویس ابری که به عنوان BehaviorCloudService مشخص شده است در طول یک دوره زمانی به عنوان مجموعه ای از همه رفتارهای SP سرویس ابری تعریف می شود.
اطلاعات فوق از طریق یک نمودار وابستگی کشش در زمان اجرا به دست می آید و آن نیز مدیریت می شود که دارای مفاهیم گره از مدل ارائه شده در شکل ۱ (به عنوان مثال، ماشین مجازی) و روابط (مثلا رابطه ی کشش) است. نمودار وابستگی کشش محصور شده است و به طور مستمر با (i) اطلاعات پیش استقرار، مانند توصیف توپولوژی سرویس (مثلا TOSCA {7}) یا نمایه سازی اطلاعات; و (ii) اطلاعات زمان اجرا مانند مقادیر متریک از ابزارهای نظارت و یا اطلاعات منابع اختصاص یافته از ارائه دهندگان ابری API به روز می شود.
۲٫۲ فرایندهای کنترل کشش
قابلیت های کشش (EC) مجموعه عملیات مربوط به یک سرویس ابری هستند که یک متولی سرویس ابری (به عنوان مثال کنترل کننده کشش) ممکن است از آن استفاده کند و بر رفتار سرویس ابری تاثیر بگذارد. چنین قابلیت هایی می تواند برای این موارد قرار داده شود: i) ) بخش های مختلف سرویس (ii) ارائه دهندگان ابر، یا (iii) منابعی که توسط ارائه دهندگان ابر تامین می شود. یک EC را می توان به عنوان نمایش انتزاعی API در نظر گرفت، که در میان ارائه دهندگان و سرویس های ابری متفاوت است. شکل ۲، زیرمجموعه های مختلفی از EC ها که برای کاربرد وب نمونه ایی ایجاد شده را نمایش می دهد هنگامیکه بر دو بستر مختلف ابری قرار می گیرد (به عنوان مثال، ابر خصوصی Flexiant و Openstack)، و همچنین EC هایی برای سرویس ابری و نرم افزار نصب شده قرار داده می شوند. سرویس ابری در هر دو بستر ابری ذکر شده باید در محیط خاص اجرا شود (به عنوان مثال، وب سرور Apache Tomcat)، و تمام این قابلیت ها، زمانی که توسط یک کنترل کننده کشش اجرا می شود، بر روی بخش های مختلف سرویس ابری تاثیر خواهد گذاشت. به عنوان مثال، قابلیت های کشش یک توپولوژی وب سرور که از سرویس ابری است حتی اگر در اولین نگاه مشهود نباشد می تواند بر عملکرد عقبه backend پایگاه داده آن تاثیر بگذارد.

۲٫۳ کشش سرویس ابری در زمان اجرا
برای اینکه قادر باشیم اثرات ECP ها بر بخش های سرویس را برآورد کنیم بر نمودار وابستگی کشش تکیه می کنیم که تمام متغیرهایی که به سیر تکامل رفتار کشش سرویس ابری کمک می کنند را ثبت می کند. سمت چپ شکل ۳، سرویس ابری در زمان پیش استقرار را نشان می دهد جایی که کنترل کننده های کشش خودکار، فقط از اطلاعات ساختاری که توسط منابع مختلف ارائه شده است در مورد آن آگاهی دارند (از جمله توضیحات سرویس TOSCA). پس از اجرای فرایند استقرار (به عنوان مثال، ایجاد ماشین x و پیکربندی نرم افزار z) نمودار وابستگی کشش بطور اضافی حاوی اطلاعات مربوط به زیرساخت های به دست آمده از ارائه دهنده ابری، و اطلاعات کشش بدست آمده از نظارت کردن سرویس ها با نشان دادن سیر تکامل متریک برای SP های مختلف خواهد شد. این اطلاعات به طور مستمر در طول زمان اجرا به روز می شود (مرحله ۳ در شکل ۳)، از این رو برای برآورد رفتار فرض می کنیم که اطلاعات کاملی داریم (یعنی هیچ اطلاعاتی کم نداریم).
منابع زیرساختی همانطور که قبلا ذکر شد با قابلیت های کشش (EC در شکل ۳) مرتبط است که تغییراتی را که باید اعمال شود و مکانیسم های راه اندازی آنها را (مانند API مختص EC) توصیف می کند. علاوه بر این یک بستر ابری، EC ها را برای ایجاد منابع جدید یا ارائه سرویس های جدید قرار می دهد (به عنوان مثال، افزایش حافظه یک EC است که برای VM قرار گرفته از این رو ایجاد VM جدید، یک EC است که برای بستر ابری قرار گرفته است). در این زمینه، برای کشف اثراتی که ECP بوجود می آورد، همبستگی بین متریک ها در هر بخش سرویس در نظر گرفته می شود که از نمودار وابستگی کشش برای آن استفاده می کنیم. این اطلاعات را تجزیه و تحلیل می کنیم تا تأثیر یک ECP در همه بخش های سرویس را مشخص کنیم، صرف نظر از این که آیا ECP یک برنامه خاص است یا هیچ پیوند آشکاری به دیگر بخش های سرویس ندارد. در حقیقت، همانطور که در بخش ۴ نشان داده شده است، تأثیر ECP های مختلف بر بخش های مختلف و در کل سرویس ابری بسیار قابل توجه است.

.۳ ارزیابی رفتار کشش سرویس ابری
راه حل های موجود که برای یادگیری مدل های رفتار [۴،۵] است، مدل های متریک گسسته را بدون همبستگی آنها با متغیرهای متعدد که بر رفتار سرویس ابری تاثیر می گذارد یاد می دهد. در مقابل آنها، در حال یادگیری رفتار بخش های سرویس ابری مختلف و ارتباط آنها با ECP های مختلف هستیم البته نه تنها با آنهایی که به طور مستقیم مرتبط هستند، همچنین تاثیر یک ECP را با توجه به همبستگی های بین چند متریک و در میان چندین بخش سرویس برآورد می کنیم. فرآیند یادگیری که برای تعیین رفتار بخش سرویس ابری استفاده شده است در شکل ۴ نشان داده شده، و با تصحیح پایگاه آگاهی که قبلا جمع آوری شده بطور پیوسته اجرا می شود.

۳٫۱ فرایند یادگیری
پردازش داده های ورودی. فرایند یادگیری ما به گونه ورودی هر سیر تکامل متریک MaS Pi (شروع، اکنون) (معادله ۳ را ببینید) از آغاز اجرای سرویس بر بستر ابری کنونی است. برای اینکه سیر تکامل مورد انتظار متریک ها در پاسخ به اجرای یک ECP خاص را برآورد کنیم برای هر متریک نظارت شده از هر بخش سرویس، یک سری زمانی مربوطه ( (RT S انتخاب می کنیم تا آن را با MaS Pi قبلی مقایسه کنیم ( شروع، اکنون ). اندازه RTS به شدت به میانگین زمانی لازم برای اجرای ECP بستگی دارد (نگاه کنید به بخش ۴٫۳). در نتیجه، متریک RTS یک زیر دنباله MaS Pi از قبل از اجرای ECP است تا زمانی که اجرا کامل می شود:

فرایند دسته بندی. برای اینکه رفتار مورد انتظاردر نتیجه ی اجرای ECP را شناسایی کنیم دسته های Clusterspi نقاط رفتاری را برای همه بخش های سرویس و برای هر ECP مبتنی بر فاصله بین نقاط رفتار طرح ریزی می کنیم همانگونه که در معادله ۶ بیان شده است. رویکرد خود را تنها با در نظر گرفتن ECP موجود برای SPi کنونی محدود نمی کنیم، همانطور که قبلا ذکر شد اجرای ECP در بخش سرویس خاص ممکن است بر رفتار یک SP دیگر یا سرویس ابری کل تاثیر بگذارد. تابع هدف این فرآیند یافتن نقطه رفتار چند بعدی C (Ɵ *) است، که فاصله بین نقاط متعلق به چنین دسته ایی را به حداقل می رساند (نگاه کنید به معادله ۷). از آنجا که تمرکز این مقاله ارزیابی کیفیت الگوریتم های دسته بندی مختلف نیست، از الگوریتم K-means استفاده کنیم، به این ترتیب جاییکه تعداد دسته ها K = √(N/2) است N تعداد اهداف می شود. با این حال همانطور که در بخش ۴ نشان داده شده است، حتی با الگوریتم ساده K-Means، رویکرد ما رفتار کشش مورد انتظار را با برآورد میزان خطا پایین حاصل می کند.

پس از اینکه دسته های نقطه ای با ابعاد S + _ECPtime را بدست آوردیم برای هرSPi یک ماتریس همبستگی GMspi [CX, Cy]، که Cx مرکز دسته x است را ایجاد می کنیم و احتمال می دهیم همه متریک های مختلف از دسته ها با هم ظاهر شوند (به عنوان مثال، افزایش قابلیت اطمینان داده ها معمولا با افزایش هزینه مرتبط است). یک بخش در CM نمایانگر نسبت بین تعداد نقاط رفتار Cx و Cy است که با هم در جهت تعداد کل نقاط رفتار درنظر گرفته می شوند. زمانی که نقاط رفتار از یک دسته به دسته دیگر حرکت می کند، یا زمانی که ECP های جدید اجرا می شوند این ماتریس بطور مداوم به روز می شود، از این رو پایگاه آگاهی افزایش می یابد.

۳٫۲ تعیین رفتار کشش مورد انتظار
در مرحله ی ایجاد رفتار موردانتظار مبتنی بر فرایند یادگیری که در شکل ۴ نشان داده شده است آخرین مقدار متریک ها را برای هر SPi یعنی M sa Pi (کنونی – s، کنونی] انتخاب می کنیم و ECP £ که کنترل کننده است برای اجرا و یا برای آن که کاربر می خواهد از این اثرات آگاهی پیدا کند در نظر گرفته می شود. رفتار مورد انتظار را دریافتیم (معادله ۸ را ببینید) که شامل یک مرکز دسته چندتایی از دسته های ساخته شده در طول فرآیند یادگیری است که در بخشی از سرویس ابری به رفتار متریک کنونی خیلی نزدیک است که ما در حال تمرکز بر آنها هستیم زیرا با هم در سراسر اجرای سرویس ابری ظاهر می شوند. نتیجه این مرحله، برای هر متریک SPi، لیستی از مقادیر مورد انتظار از اجرای ECP £ است (به عنوان مثال مقادیر مورد انتظار از هر متریک برای این مورد که کاربر می خواهد یک سرویس جدید وب از نوع X را در همان محفظه برنامه وب قرار دهد).

۴٫ آزمایش ها
برای اینکه اثربخشی رویکرد پیشنهادی را ارزیابی کنیم چارچوب ADVISE که شامل مفاهیمی است که قبلا شرح داده شده را توسعه داده ایم. نسخه ADVISE کنونی انواع مختلفی از اطلاعات را برای پر کردن نمودار وابستگی کشش جمع آوری می کند مانند: (i) اطلاعات ساختاری، از توصیف سرویس TOSCA؛(ii) اطلاعات عملکرد کاربردی و زیرساخت از سیستم های نظارت JCatascopia (9) و MELA (6) (iii) اطلاعات کشش مربوط به ECP از کنترل کننده کشش rSYBL (8) که در آن یک پلاگین اجرایی را گسترش دادیم تا ECP ها به طور تصادفی بر روی سرویس های ابری اجرا شوند. برای اینکه عملکرد چارچوب ADVISEرا ارزیابی کنیم تست بدی testbed متشکل از دو سرویس مستقر در ابر عمومی Flexiant ایجاد کردیم. در هر دو سرویس ابری، ECP های تصادفی را که در بخش های مختلف سرویس قرار گرفته اند اجرا می کنیم. از کنترل کننده منطقی استفاده نمی کنیم، زیرا علاقه مند به برآورد رفتار کشش تمام بخش های سرویس در نتیجه ی اجرای تصمیم کنترل کشش خوب و بد هستیم.