پروژه کلودسیم+(52361)

سلام وقتتون بخیر ببخشید من یه پروژه شبیه سازی با کلودسیم داشتم یه معماریه که باید شبیه سازی بشه اگه ویس بدم که مشکلی نداره؟ من میخوام این معماری که براتون فرستادم رو پیاده سازیش کنم اگه بخوام یه توضیح در مورد این معماری بدم، همونطور که میبینید این معماری از سه لایه تشکیل شده. در واقع یه معماری ترکیبی از ابر و مه هستش. توی این معماری درخواست ها از طریق دستگاه های iot به وجود میاند. هر درخواست یک مقدار واحد پردازشی و یک مقدار ظرفیت پهنای باند نیاز دارند، این از ماهیت درخواست ها. لایه یک از تعدادی واحد کنترل به اسم cp تشکیل شده که این تعداد i تا هستش. هر cp یک تعداد سرور تحت مدیریت خودش داره که فرض میکنیم s تا هستش. هر cp وظیفه داره درخواست های تولید شده توسط یک تعداد دستگاه iot رو دریافت کنه و مشخص کنه که این درخواست کجا باید اجرا بشه(به عبارتی یک الگوریتم لود بلنسینگ اجرا کنه که این رو هم توضیح میدم). لایه دو تشکیل شده از یک کنترلر که کار cp رو انجام میده. یعنی یکسری سرور تحت کنترل خودش داره. و مشخص میکنه هر درخواست وارد شده به لایه دو، روی کدوم سرور اجرا بشه. لایه سوم هم که لایه ابر هستش این از توضیح هر لایه تفاوت لایه ها با هم، قدرت پردازشی سرورهای موجود در اون لایه هستش که. به عبارتی سرور های لایه یک قدرت پردازشی کمتری نسبت به سایر لایه ها و سرور های ابر قدرت پردازشی بالاتری نسبت به سایر لایه ها دارند. نکته بعدی که وجود داره اینه که دستگاه های iot از لایه ها فاصله دارند، و به عبارتی یک پهنای باندی هم لازم است که درخواست ها به لایه های مختلف ارسال بشن(این رو هم آخر سر توضیح میدم که چرا اصلا مطرح شدن) حالا اگه بخوام روال کار رو توضیح بدم به این صورت هستش که درخواست ها در مرحله اول ارسال میشن به cp مربوطشون. cp با توجه به یک مقدار آستانه که بارکاری خودش هست، متوجه میشه که آیا میتونه این درخواست رو همینجا انجام بده یا خیر. حالت هایی که ممکنه پیش بیاد اینه که لازمه درخواست ارسال بشه به یک cp دیگه، یا لایه یک یا نه، ارسال بشه به ابر(ترتیب انتخاب باید به همین صورت باشه یعنی در مرحله اول سعی میشه که حتما این درخواست در لایه یک انجام بشه بعد لایه های بالاتر چون میخوایم پهنای باند کمتری مصرف بشه، و همونطور که گفتم با افزایش لایه ها پهنای باند بیشتری لازمه).پس همینطور که مشخصه سه تا مقدار آستانه لازمه. یکی برای حالتی که مشخص بشه میتونه توی cp فعلی اجرا بشه، یکی برای حالتی که متوجه بشیم میتونیم روی cp های دیگه اجرا کنیم یکی دیگه هم برای اینکه متوجه بشیم در لایه دو قابل انجامه و اگر منابع درخواستی بیشتر از مقدار آستانه سوم بود که متوجه میشیم باید در ابر این درخواست اجرا بشه.(این مقادیر آستانه باید بصورت دوره ای آپدیت بشن) این کلیات معماری بود الگوریتم تعادل بار رو هم بگم بهتون که به چه صورته: همینطور که میبیند این یک الگوریتم تعادل بار متمرکزه، درخواست ها داخل یک واحد کنترل کننده مرکزی جمع میشن و بر اساس اون تصمیم گیری میشه که به کدوم سرور برن، هر واحد کنترل کننده مرکزی از یک صف تشکیل شده. هر عنصر این صف بیانگر آیدی و بار کاری سرورهای تحت کنترل کنترل کننده مرکزی هستند. این صف، یک صف مرتب شده بصورت صعودی بر اساس بارکاری سرور ها هستش. توی این الگوریتم دو مقدار آستانه thigh و tmin داریم(طبق یک رابطه ای محاسبه میشن). thigh ماکزیمم مقدار بارکاری و tmin مینیمم مقدار بارکاری هستش. این دو مقدار باعث میشن صف به سه بخش بار متعادل، بار کم و بار زیاد تقسیم بشه. حالا روال کار به این صورت هستش که سرور ها بصورت دوره ای، بار کاری خودشون رو به کنترل کننده مرکزی ارسال میکنند، و صف خودشون رو بروز میکنند. اگر زمانی اتفاق بیفته که یک سرور در قسمت بار کاری کم صف و یک سرور در قسمت بار کاری زیاد صف باشد، الگوریتم با استفاده از یک رابطه ای مقدار بار انتقالی را محاسبه میکند و از سروری که بار کاری زیاد دارد به سروری که بار کاری کم دارد ارسال میکند. در اینصورت تعادل بار انجام میشه. حالا این الگوریتم جزئیات بیشتری هم داره ولی اگه لازم شد من باقی مطالب رو هم میگم بهتون نکته آخر هم اینکه مثل همه ی الگوریتم های تعادل بار که یک هدفی رو دنبال میکنند، هدف از این الگوریتم تعادل بار اینه که هزینه اجرای درخواست ها کم بشه، در اینجا هزینه پهنای باند و هزینه استفاده از سرور ها مطرح هستش به خاطر همینه که من چند خط قبلی گفتم بهتون که هدف اینه که ابتدا در لایه یک بعد در لایه دو و نهایت در لایه ابر اجرا بشه، چون با افزایش سطح لایه ها هزینه پهنای باند و هزینه استفاده از سرور ها افزایش پیدا میکنه