بزرگترین کاری که OpenMosix انجام میدهد، تبدیل دستهای از ماشینهای لینوکس به یک سیستم بزرگ مجازی چند پردازندهای متقارن (SMP=Symmetric MultiProcessor) است. هرچند نحوه عملکرد آن با سیستمهای SMP واقعی مقداری تفاوت دارد. نخست اینکه سیستمهای واقعی SMP که مبتنی بر ۲ یا چند پردازنده هستند، میتوانند اطلاعات را با سرعت بسیار بالا تبادل نمایند، در صورتی که در OpenMosix سرعت ارتباط بین گرههای کلاستر، محدود به سرعت شبکه محلی است که گرهها در آن قرار دارند. استفاده از ارتباطات اترنت گیگابیت و یا سایر انواع پر سرعت اترنت باعث خواهد شد تا تبادل دادهها با سرعت بالاتری صورت گرفته و کارایی کلاستر بالاتر باشد.
البته OpenMosix دارای مزایایی نسبت به سیستمهای چند پردازندهای سنتی داراست. با استفاده از OpenMosix شما قادر به ایجاد کلاسترهایی حاوی دها و حتی صدها کامپیوتر با سختافزار ارزان هستید در حالی که سیستمهای SMP که حاوی تعداد زیادی پردازنده باشند، میتوانند بسیار گرانقیمت باشند. برای بسیاری از برنامههای کاربردی، OpenMosix نسبت به سیستمهای SMP یا Mainframe، حرف بیشتری برای گفتن دارد. البته دلیلی وجود ندارد که شما نتوانید OpenMosix را بر روی سیستمهای قدرتمند چند پردازندهای اجرا نمایید. حتی این امکان وجود دارد تا OpenMosix را به همراه برنامههای کاربردی که با MPI یا PVM توسعه یافتهاند، اجرا نمایید تا سرعت کلاستر خود را بهینه نمایید.
همانند سیستمهای SMP سنتی، OpenMosix قادر نیست تا یک پروسه را روی چند پردازنده فیزیکی اجرا نماید. واضحتر اینکه نباید انتظار داشته باشید تا اجرای برنامهای مانند مرورگر موزیلا روی یک کلاستر سریعتر از یک سیستم تک پردازندهای باشد، مگر اینکه اجرا پروسه آنرا به یک گره سریعتر روی کلاستر منتقل نمایید. بعلاوه در حال حاضر OpenMosix امکان جداسازی رشتههای متعدد به هم پیوسته را از یکدیگر فراهم نمیکند.
اما OpenMosix قادر است تا پروسههای استاندارد لینوکس را بین گرههای کلاستر بدون مشکل مهاجرت دهد. در صورتی که یک برنامه کاربردی تعداد زیادی زیر پروسه داشته باشد، آنگاه OpenMosix قادر است تا هر یک از آنها را به یک گره مناسب در کلاستر منتقل کند. شما میتوانید از این قابلیت حتی در برنامههای کاربردی که دارای زیر پروسه نیستند نیز استفاده کنید. برای مثال، در صورتی که نیاز دارید تا تعدادی فایل موسیقی را از فرمت wav به mp۳ تبدیل نمایید، تبدیل هر فایل یک پروسه خواهد بود.
شما میتوانید تمام این پروسهها را یکجا اجرا نمایید. در آنصورت عمل پردازش بین کلاستر پخش خواهد شد (بجای اینکه عملیات تبدیل فایلها را یک به یک انجام دهید). در صورتی که شما ۱۲ فایل موسیقی و ۱۲ گره همسان داشته باشید، عملیات تبدیل ۱۲ بار سریعتر انجام خواهد شد.
● Mosix در برابر OpenMosix
پروژه OpenMosix جدیدترین شعبه پروژه Mosix میباشد که یکی از اهداف آن فراهم کردن کلاستر سازی نامحسوس روی لینوکس است. پس چرا ما از OpenMosix استفاده کنیم؟ دلایل خوبی برای این امر وجود دارد.
در اواخر سال ۲۰۰۱ رهبری پروژه Mosix تصمیم به انتشار نسخههای جدیدی از Mosix تحت مجوزهای غیر GPL گرفت (کدهایی که قبلا GPL بودند). بنابراین نسخههای جدید Mosix دیگر نرمافزار آزاد نبودند و حقوق کاربران نیز در آنها نامشخص بود و هیچ مانعی برای نویسنده Mosix وجود نداشت تا از کاربران درخواست پرداخت وجه نماید.
این تغییر مجوز باعث ایجاد نگرانیهایی در میان کاربران Mosix شد و برداشته شدن کدهای منبع و حذف لیستهای پستی Mosix بدون توضیح موجه، این نگرانی را تشدید نمود. خوشبختانه این کاربران تنها کسانی نبودند که در باره این تغییرات جدید نگران بودند. موشه بار (Moshe Bar) یکی از مدیران پروژه Mosix با این تغییر مجوز از GPL موافق نبود.
بنابراین وی پروژه OpenMosix را شروع کرد تا این اطمبنان حاصل شود که ارائه نسخه آزاد و رایگان Mosix به عموم مردم ادامه پیدا خواهد کرد. سایت رسمی پروژه OpenMosix در آدرس https://openmosix.sf.net یا https://openmosix.org قرار دارد.
پس از آغاز این پروژه، تعداد زیادی از کاربران Mosix به OpenMosix روی آوردند. سیاست توسعه باز موشه باعث شد تا توسعه OpenMosix سرعت بیشتری بگیرد. در حال حاصر ۱۴ نفر بطور فعال روی پروژه OpenMosix کار میکنند در حالی که تعداد افراد پروژه Mosix تنها ۴ نفر است. در حال حاضر تعداد زیادی رفع اشکال، بهینه سازی سرعت و بهینه سازی در کدهای OpenMosix صورت گرفته است و تعدادی قابلیت جدید و بهینه سازی مجدد در سرعت نیز بزودی ارائه خواهند شد.
در حقیت جدا شدن پروژه OpenMosix از Mosix باعث ارائه راهحلهای بهتری برای کلاستر سازی تحت سیستمعامل لینوکس فراهم نموده است.
🐧 @iranopensource
البته OpenMosix دارای مزایایی نسبت به سیستمهای چند پردازندهای سنتی داراست. با استفاده از OpenMosix شما قادر به ایجاد کلاسترهایی حاوی دها و حتی صدها کامپیوتر با سختافزار ارزان هستید در حالی که سیستمهای SMP که حاوی تعداد زیادی پردازنده باشند، میتوانند بسیار گرانقیمت باشند. برای بسیاری از برنامههای کاربردی، OpenMosix نسبت به سیستمهای SMP یا Mainframe، حرف بیشتری برای گفتن دارد. البته دلیلی وجود ندارد که شما نتوانید OpenMosix را بر روی سیستمهای قدرتمند چند پردازندهای اجرا نمایید. حتی این امکان وجود دارد تا OpenMosix را به همراه برنامههای کاربردی که با MPI یا PVM توسعه یافتهاند، اجرا نمایید تا سرعت کلاستر خود را بهینه نمایید.
همانند سیستمهای SMP سنتی، OpenMosix قادر نیست تا یک پروسه را روی چند پردازنده فیزیکی اجرا نماید. واضحتر اینکه نباید انتظار داشته باشید تا اجرای برنامهای مانند مرورگر موزیلا روی یک کلاستر سریعتر از یک سیستم تک پردازندهای باشد، مگر اینکه اجرا پروسه آنرا به یک گره سریعتر روی کلاستر منتقل نمایید. بعلاوه در حال حاضر OpenMosix امکان جداسازی رشتههای متعدد به هم پیوسته را از یکدیگر فراهم نمیکند.
اما OpenMosix قادر است تا پروسههای استاندارد لینوکس را بین گرههای کلاستر بدون مشکل مهاجرت دهد. در صورتی که یک برنامه کاربردی تعداد زیادی زیر پروسه داشته باشد، آنگاه OpenMosix قادر است تا هر یک از آنها را به یک گره مناسب در کلاستر منتقل کند. شما میتوانید از این قابلیت حتی در برنامههای کاربردی که دارای زیر پروسه نیستند نیز استفاده کنید. برای مثال، در صورتی که نیاز دارید تا تعدادی فایل موسیقی را از فرمت wav به mp۳ تبدیل نمایید، تبدیل هر فایل یک پروسه خواهد بود.
شما میتوانید تمام این پروسهها را یکجا اجرا نمایید. در آنصورت عمل پردازش بین کلاستر پخش خواهد شد (بجای اینکه عملیات تبدیل فایلها را یک به یک انجام دهید). در صورتی که شما ۱۲ فایل موسیقی و ۱۲ گره همسان داشته باشید، عملیات تبدیل ۱۲ بار سریعتر انجام خواهد شد.
● Mosix در برابر OpenMosix
پروژه OpenMosix جدیدترین شعبه پروژه Mosix میباشد که یکی از اهداف آن فراهم کردن کلاستر سازی نامحسوس روی لینوکس است. پس چرا ما از OpenMosix استفاده کنیم؟ دلایل خوبی برای این امر وجود دارد.
در اواخر سال ۲۰۰۱ رهبری پروژه Mosix تصمیم به انتشار نسخههای جدیدی از Mosix تحت مجوزهای غیر GPL گرفت (کدهایی که قبلا GPL بودند). بنابراین نسخههای جدید Mosix دیگر نرمافزار آزاد نبودند و حقوق کاربران نیز در آنها نامشخص بود و هیچ مانعی برای نویسنده Mosix وجود نداشت تا از کاربران درخواست پرداخت وجه نماید.
این تغییر مجوز باعث ایجاد نگرانیهایی در میان کاربران Mosix شد و برداشته شدن کدهای منبع و حذف لیستهای پستی Mosix بدون توضیح موجه، این نگرانی را تشدید نمود. خوشبختانه این کاربران تنها کسانی نبودند که در باره این تغییرات جدید نگران بودند. موشه بار (Moshe Bar) یکی از مدیران پروژه Mosix با این تغییر مجوز از GPL موافق نبود.
بنابراین وی پروژه OpenMosix را شروع کرد تا این اطمبنان حاصل شود که ارائه نسخه آزاد و رایگان Mosix به عموم مردم ادامه پیدا خواهد کرد. سایت رسمی پروژه OpenMosix در آدرس https://openmosix.sf.net یا https://openmosix.org قرار دارد.
پس از آغاز این پروژه، تعداد زیادی از کاربران Mosix به OpenMosix روی آوردند. سیاست توسعه باز موشه باعث شد تا توسعه OpenMosix سرعت بیشتری بگیرد. در حال حاصر ۱۴ نفر بطور فعال روی پروژه OpenMosix کار میکنند در حالی که تعداد افراد پروژه Mosix تنها ۴ نفر است. در حال حاضر تعداد زیادی رفع اشکال، بهینه سازی سرعت و بهینه سازی در کدهای OpenMosix صورت گرفته است و تعدادی قابلیت جدید و بهینه سازی مجدد در سرعت نیز بزودی ارائه خواهند شد.
در حقیت جدا شدن پروژه OpenMosix از Mosix باعث ارائه راهحلهای بهتری برای کلاستر سازی تحت سیستمعامل لینوکس فراهم نموده است.
🐧 @iranopensource
🔴 با عرض سلام، ادب و احترام، خدمت همه متخصصین عزیز. با Part-6 از سری آموزش های Citrix XenServer در خدمت شما هستیم. با ما همراه باشید.
تأیید patchها بحرانی برای XenServer 7.0
بعد از اینکه نصب/بروزرسانی XenServer بصورت موفقیتآمیز انجام شد، حال زمان آن فرا میرسد تا اقدام به ایجاد ماشینهای مجازی، شبکه و منابع ذخیرهسازی نماییم. اما پیش از آن میبایست patchهای بحرانی را از طریق نرمافزار XenCenter تأیید نماییم. برای این منظور به سادگی از منوی Tools گزینه Install Upgrade را همانند شکل 108 انتخاب نمایید.
بعد از اینکه نصب/بروزرسانی XenServer بصورت موفقیتآمیز انجام شد، حال زمان آن فرا میرسد تا اقدام به ایجاد ماشینهای مجازی، شبکه و منابع ذخیرهسازی نماییم. اما پیش از آن میبایست patchهای بحرانی را از طریق نرمافزار XenCenter تأیید نماییم. برای این منظور به سادگی از منوی Tools گزینه Install Upgrade را همانند شکل 108 انتخاب نمایید.
سپس در پنجرهای که همانند شکل 109 ظاهر میشود، اطلاعاتی درباره پروسه نصب patch داده شده که فقط کافیست بعد از مطالعه آن بر روی دکمه Next کلیک کنید.
در صورتیکه XenCenter به اینترنت متصل شده باشد، قادر به مشخص کردن موقعیت هر patchی که مورد نیاز میباشد. همانطور که در شکل 110 مشاهده میکنید، در زمان تألیف کتاب حاضر تنها patchی که موجود بود، 'XS70E004' بوده که میبایست فوراً جهت نصب و بروزرسانی XenServer مورد تأیید قرار گیرد.
در پنجره بعدی همانند شکل 111، میبایست host(هایی) را که قصد دارید تا patch(های) مورد نظرتان بر روی آنها اعمال شوند، انتخاب نموده و سپس بر روی دکمه Next کلیک کنید.
بعد از کلیک بر روی دکمه Next در شکل فوق، XenCenter شروع به دانلود patch(های) مورد نظر و push کردن آنها به سرورهای انتخاب شده میکند. در این مرحله کافیست مقداری منتظر بمانید تا پروسه مربوطه کامل شود، سپس بر روی دکمه Next کلیک کنید.
بعد از اینکه patch فایلها update شدند، XenCenter یکسری از بررسیها را انجام خواهد داد تا مطمئن شود که شرایط خاصی که مدنظرش است قبل از نصب patchها و reboot شدن hostها صورت گرفته است یا خیر.
بعد از اینکه پیش بررسیها کامل شد، XenCenter به administrator اعلام خواهد کرد که چطور میبایست مراحل بعد از نصب یا اصطلاحاً post installation صورت گیرد. بدون اینکه دلیل قانع کنندهای وجود داشته باشد میتوانید با مشاهده پنجره شکل 114 و انتخاب گزینه اول به XenCenter اجازه دهید این وظایف را بصورت معمول انجام دهد و سپس بر روی دکمه Install update کلیک کنید.
با مشاهده صفحه Install the update همانند شکل 115، پروسه پیشرفت نصب patchها نمایش داده میشود و در صورتیکه errorی وجود داشته باشد پیغامی به administrator نشان داده خواهد شد.
Migrate کردن از XenServer فیزیکی به مجازی
در این بخش قصد داریم به مفاهیم migration یا مهاجرت از سرور فیزیکی به مجازی (P2V ) در محیط XenServer بپردازیم. پروسه انتقال یک سرور فیزیکی به یک سرور مجازی متأسفانه دارای داکیومنتهای ضعیفی در XenServer است. پیش از این ابزارهایی برای این نوع migration در دسترس ادمینهای شبکه بود اما با ظهور XenServer 6.5 دیگر آن ابزارهای جدا از نصاب XenServer نیستند.
در این بخش با استفاده از ابزار Open Sourceی به نام Clonezilla یک image از دیسک XenServer گرفته میشود و در Samba server روی شبکه ذخیره خواهد شد و سپس یک guest مجازی بر روی سیستم XenServer ایجاد خواهد شد. ماشین مجازی ایجاد شده دارای هیچگونه سیستمعاملی نیست بنابراین از PXE boot جهت نصب Clonezilla و سپس گرفتن image و pull کردن آن از Samba server و قرار دادن بر روی هارددیسک مجازی (VDI) جدید ایجاد شده استفاده خواهیم کرد.
پیشنیازهای سیستم:
XenServer 6.5
Clonezilla Live- Imaging Software
PXE boot server با Clonezilla PXE bootable: https://clonezilla.org/livepxe.php
Samba Server با فضای ذخیرهسازی کافی جهت ذخیره کردن image مربوط به guest فیزیکی
توجه: جهت دریافت نرمافزار Clonezilla میتوانید به آدرس زیر مراجعه نمایید:
https://clonezilla.org/downloads.php
Image گرفتن از Physical Server
اولین بخش این پروسه Image گرفتن از سرور فیزیکی است که از طریق PXE booting Clonezilla Live انجام میشود اما میتوان این کار را با Clonezilla Live از طریق USB یا CR-ROM نیز انجام داد. زمانیکه عملیات boot مربوط به Clonezilla به اتمام میرسد، screenی همانند شکل 116 مشاهده خواهید نمود که منتظر تعیین گام بعدی که "Start_Clonezilla" است میباشد.
در این بخش قصد داریم به مفاهیم migration یا مهاجرت از سرور فیزیکی به مجازی (P2V ) در محیط XenServer بپردازیم. پروسه انتقال یک سرور فیزیکی به یک سرور مجازی متأسفانه دارای داکیومنتهای ضعیفی در XenServer است. پیش از این ابزارهایی برای این نوع migration در دسترس ادمینهای شبکه بود اما با ظهور XenServer 6.5 دیگر آن ابزارهای جدا از نصاب XenServer نیستند.
در این بخش با استفاده از ابزار Open Sourceی به نام Clonezilla یک image از دیسک XenServer گرفته میشود و در Samba server روی شبکه ذخیره خواهد شد و سپس یک guest مجازی بر روی سیستم XenServer ایجاد خواهد شد. ماشین مجازی ایجاد شده دارای هیچگونه سیستمعاملی نیست بنابراین از PXE boot جهت نصب Clonezilla و سپس گرفتن image و pull کردن آن از Samba server و قرار دادن بر روی هارددیسک مجازی (VDI) جدید ایجاد شده استفاده خواهیم کرد.
پیشنیازهای سیستم:
XenServer 6.5
Clonezilla Live- Imaging Software
PXE boot server با Clonezilla PXE bootable: https://clonezilla.org/livepxe.php
Samba Server با فضای ذخیرهسازی کافی جهت ذخیره کردن image مربوط به guest فیزیکی
توجه: جهت دریافت نرمافزار Clonezilla میتوانید به آدرس زیر مراجعه نمایید:
https://clonezilla.org/downloads.php
Image گرفتن از Physical Server
اولین بخش این پروسه Image گرفتن از سرور فیزیکی است که از طریق PXE booting Clonezilla Live انجام میشود اما میتوان این کار را با Clonezilla Live از طریق USB یا CR-ROM نیز انجام داد. زمانیکه عملیات boot مربوط به Clonezilla به اتمام میرسد، screenی همانند شکل 116 مشاهده خواهید نمود که منتظر تعیین گام بعدی که "Start_Clonezilla" است میباشد.