در نهایت با مشاهده پنجرهای همانند شکل 167، تمامی پیکربندیهای انجام شده را یکبار بررسی نموده و در صورتیکه همه چیز درست است، تنها بر روی دکمه Finish کلیک نمایید تا عملیات migration ماشین مجازی آغاز شود.
توجه کنید در صورتیکه Storageی را برای migration پیشتر پیکربندی نکردهاید، عملیات انتقال ماشین مجازی از یک host به host دیگه چند دقیقهای به طول خواهد انجامید.
Storage XenMotion چیست؟
در واقع Storage XenMotion قابلیتی است که به یک ماشین مجازی اجازه میدهد تا از یک SR به SR دیگر مهاجرت یا migrate نماید، در حالیکه ماشین مجازی در حالت Power on (روشن) قرار دارد. قابلیت Storage XenMotion تقریباً از نظر مفهوم کاری شبیه به XenMotion عمل میکند و برای منتقل کردن ماشینهای مجازی بین سرورهای فیزیکی مورد استفاده قرار میگیرد اما نکته مهم در این است که در Storage XenMotion این فایل سیستم و هارددیسکهای مجازی هستند که به همراه تمامی مخلفات یک ماشین مجازی (VDIها) به سرور دیگر منتقل میشوند.
در پیادهسازی XenMotion تنها وجود یک SAN Storage کفایت میکرد اما برای راهاندازی Storage XenMotion معمولاً به دو یا بیشتر از دو عدد SAN Storage نیاز است و فایلهای ماشینهای مجازی از یک Storage به Storage دیگر توسط فرآیندStorage XenMotion منتقل میشوند. انجام این فرآیند نیز مانند فرآیند XenMotion هیچگونه تأثیری در سرویسدهی به کاربران نخواهد داشت و آنها این تغییر را احساس نمیکنند.
در واقع Storage XenMotion قابلیتی است که به یک ماشین مجازی اجازه میدهد تا از یک SR به SR دیگر مهاجرت یا migrate نماید، در حالیکه ماشین مجازی در حالت Power on (روشن) قرار دارد. قابلیت Storage XenMotion تقریباً از نظر مفهوم کاری شبیه به XenMotion عمل میکند و برای منتقل کردن ماشینهای مجازی بین سرورهای فیزیکی مورد استفاده قرار میگیرد اما نکته مهم در این است که در Storage XenMotion این فایل سیستم و هارددیسکهای مجازی هستند که به همراه تمامی مخلفات یک ماشین مجازی (VDIها) به سرور دیگر منتقل میشوند.
در پیادهسازی XenMotion تنها وجود یک SAN Storage کفایت میکرد اما برای راهاندازی Storage XenMotion معمولاً به دو یا بیشتر از دو عدد SAN Storage نیاز است و فایلهای ماشینهای مجازی از یک Storage به Storage دیگر توسط فرآیندStorage XenMotion منتقل میشوند. انجام این فرآیند نیز مانند فرآیند XenMotion هیچگونه تأثیری در سرویسدهی به کاربران نخواهد داشت و آنها این تغییر را احساس نمیکنند.
از این قابلیت معمولاً زمانیکه Storage arrayهای خود را بروزرسانی و update میکنید و یا حتی migrate کردن Storage arrayها بدون downtime ماشین مجازی استفاده میشود. XenServer به شما اجازه Live migrate یک ماشین مجازی شامل VDIها از یک local SR به یک shared SR (از یک سرور به سایر سرورها) بدون نیاز به Shared Storage را نیز فراهم میکند. این قابلیت چیزی شبیه به قابلیت Storage vMotion در VMware ESXi است.
مکانیزم کاری Storage XenMotion با استفاده از کپی کردن اطلاعات Metadata مربوط به VM به Storage دیگر شروع میشود که این اطلاعات در Home Directory قرار دارند. سپس نرمافزار با استفاده از قابلیتی به نام Changed Block Tracking یا CBT فایلهای دیسک مجازی را به محل جدید منتقل میکند، CBT برای مطمئن شدن از صحت و کامل بودن انتقال هارددیسکهای مجازی استفاده میشود و همزمان عملیات Replication نیز برای اطمینان از تمام و کمال بودن دادهها انجام میگیرد. زمانیکه فرآیند انتقال هارددیسک مجازی با موفقیت انجام شد ماژول CBT مجدداً برای یک کپی دیگر از اطلاعات هارددیسک قبلی از سرور قبلی میگیرد تا در صورت بوجود آمدن تغییرات جدید بلوکهای داده تغییرات جدید به Storage جدید منتقل شوند. بعد از اینکه کپی از اطلاعات هارددیسک بصورت تمام و کمال انجام شد و فرآیند Sync نیز تمام شد، ماشین مجازی قبلی در حالت Suspend قرار میگیرد و محل جدید هارددیسک به آن معرفی میشود.
قبل از اینکه XenServer ماشین مجازی را از حالت Suspend به حالت Resume در بیاورد برای آخرین بار یکبار دیگر فرآیند Replication نیز انجام میشود و در نهایت فایلهای Home Directory و دیسک قبلی از محل قبلی حذف شده و در محل جدید اجرا میشوند. کل این فرآیند برای کاربران و حتی خود VM نامحسوس است و کسی از این انتقال مطلع نخواهد شد. قابلیتStorage XenMotion استفادههای متعددی دارد که شامل منتقل کردن دیسکهای مجازی از SAN Storage قدیمی به دستگاه SAN Storage جدید، استفاده شدن به عنوان یک Load Balancer و حتی منتقل کردن دیسکهای مجازی ازLocal Hard Disk های سرورها به SAN Storageها را نیز میتواند انجام دهد، برای مثال زمانیکه شما میخواهید SAN Storage خود را تعمیر کنید و نمیخواهید سرویسدهی شما قطع شود از این روش میتوانید استفاده کنید.
قبل از اینکه XenServer ماشین مجازی را از حالت Suspend به حالت Resume در بیاورد برای آخرین بار یکبار دیگر فرآیند Replication نیز انجام میشود و در نهایت فایلهای Home Directory و دیسک قبلی از محل قبلی حذف شده و در محل جدید اجرا میشوند. کل این فرآیند برای کاربران و حتی خود VM نامحسوس است و کسی از این انتقال مطلع نخواهد شد. قابلیتStorage XenMotion استفادههای متعددی دارد که شامل منتقل کردن دیسکهای مجازی از SAN Storage قدیمی به دستگاه SAN Storage جدید، استفاده شدن به عنوان یک Load Balancer و حتی منتقل کردن دیسکهای مجازی ازLocal Hard Disk های سرورها به SAN Storageها را نیز میتواند انجام دهد، برای مثال زمانیکه شما میخواهید SAN Storage خود را تعمیر کنید و نمیخواهید سرویسدهی شما قطع شود از این روش میتوانید استفاده کنید.
مهاجرت یا Migrate یک VM با استفاده از Storage XenMotion
جهت انتقال یا migrate یک ماشین مجازی از یک SR به SR دیگر میبایست بصورت زیر عمل نمایید:
ابتدا با نرمافزار XenCenter به سرور مبدأ خود یا اصطلاحاً Source Server متصل شده و سپس از تب Storage همانند شکل 170 بروید. در ادامه VDI مورد نظر را جهت migrate با کلیک کردن بر روی آن انتخاب نموده و بعد بر روی دکمه Move در پایین پنجره کلیک نمایید.
جهت انتقال یا migrate یک ماشین مجازی از یک SR به SR دیگر میبایست بصورت زیر عمل نمایید:
ابتدا با نرمافزار XenCenter به سرور مبدأ خود یا اصطلاحاً Source Server متصل شده و سپس از تب Storage همانند شکل 170 بروید. در ادامه VDI مورد نظر را جهت migrate با کلیک کردن بر روی آن انتخاب نموده و بعد بر روی دکمه Move در پایین پنجره کلیک نمایید.
حال با مشاهده پنجره Move Virtual Disk همانند شکل 171، کافیست SR مورد نظر خود را جهت انتقال VDI انتخاب شده به آن انتخاب نموده و سپس جهت شروع پروسه migrate بر روی Move کلیک کنید.
توجه داشته باشید که مدت زمان عملیات migrate کردن به سرعت شبکه و اینترفیس managment، اندازه VDI و سرعت Storage شما بستگی دارد.
✳️ پایان Part-8. امیدوارم این بخش از آموزش نیز مورد توجه شما قرار گرفته باشد. فرداشب با بخش نهم و پایانی این دوره رأس ساعت 21:00 در خدمت شما عزیزان خواهیم بود. شب خوش میثم ناظمی
مشاهده log ها در systemd
#journalctl
لاگ گیری و گزارش فعالیت هایی که در طول چرخه حیات یک سیستم عامل اتفاق می افتد نه تنها برای سیس ادمین ها که گاهی برای کاربران عادی امری حیاتی ست.از آن جهت که گاهی تنها مشاهده گذرا به لاگ های سیستم میتواند بسیاری از مشکلات لاینحل را به آسانی حل کند.در این آموزش کوتاه قصد داریم شما را با یکی از اجزای حیاتی systemd یعنی journalctl آشنا کنیم.
فرض کنید پس از آپدیت سیستم تون دیگه نمی تونید به هیچ عنوان لاگین کنید.سناریوهایی که افراد تو این شرایط در نظر میگیرن بسته به وخامت اوضاع ممکنه متغیر باشه.بعضی ها سریع یه دیسک لایو رو مهیا میکنن و سیستم رو احیا میکنن. بعضی ها دست به دامن سایت ها و فروم ها میشن و هر چی دست شون میاد رو میزنن تا بالاخره مشکل رو حل کنن. اما..آیا دوست ندارین خودتون متخصص لاگ خونی بشین و بتونید گلیم خودتون رو از آب بکشین بیرون؟ اگه جواب تون آره هست. پس بیاین ادامه بدیم:
دستور مقدماتی برای کار با journalctl :
journalct
که بازدنش، مجموعه انبوهی از سطر های پی در پی به شما نمایش داده میشه. فعالیت هایی که یا در "سطح کرنل" اتفاق افتادن یا در "سطح کاربر"
برای مشاهده آخرین لاگ های پس از واپسین ورودتون به سیستم
journalctl -b -1
برای مشاهده لیست بوت هایی که به سیستم انجام دادین:
journalctl —list-boots
برای مشاهده لاگ ها در محدوده زمانی خاص:
journalctl --since "2015-01-10" --until "2015-01-11 03:00"
یکم خودمونی ترش😁:
journalctl --since yesterday
لاگ خونی بر اساس یونیت های systemd:
برای اینکه مثلا بخواید کل لاگ های مربوط به nginx رو در بیارین:
journalctl -u nginx.service
دستور بالا با دادن پارامتر زمانی دلخواه:
journalctl -u nginx.service --since today
لاگ گیری از فعالیت های کرنل:
journalctl -k
بر اساس مسیج های حیاتی لاگ ها:
journalctl -p emerg -b
*نکته:مسیج ها در سیستم به چند دسته تقسیم میشن:(براساس حساسیت نوع پیغام)
0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug
که دستور بالا به ما فقط لاگ های فوق حساس رو نشون میده.ن
و در نهایت برای مشاهده n لاگ واپسین:
journalctl -n 20
#journalctl
لاگ گیری و گزارش فعالیت هایی که در طول چرخه حیات یک سیستم عامل اتفاق می افتد نه تنها برای سیس ادمین ها که گاهی برای کاربران عادی امری حیاتی ست.از آن جهت که گاهی تنها مشاهده گذرا به لاگ های سیستم میتواند بسیاری از مشکلات لاینحل را به آسانی حل کند.در این آموزش کوتاه قصد داریم شما را با یکی از اجزای حیاتی systemd یعنی journalctl آشنا کنیم.
فرض کنید پس از آپدیت سیستم تون دیگه نمی تونید به هیچ عنوان لاگین کنید.سناریوهایی که افراد تو این شرایط در نظر میگیرن بسته به وخامت اوضاع ممکنه متغیر باشه.بعضی ها سریع یه دیسک لایو رو مهیا میکنن و سیستم رو احیا میکنن. بعضی ها دست به دامن سایت ها و فروم ها میشن و هر چی دست شون میاد رو میزنن تا بالاخره مشکل رو حل کنن. اما..آیا دوست ندارین خودتون متخصص لاگ خونی بشین و بتونید گلیم خودتون رو از آب بکشین بیرون؟ اگه جواب تون آره هست. پس بیاین ادامه بدیم:
دستور مقدماتی برای کار با journalctl :
journalct
که بازدنش، مجموعه انبوهی از سطر های پی در پی به شما نمایش داده میشه. فعالیت هایی که یا در "سطح کرنل" اتفاق افتادن یا در "سطح کاربر"
برای مشاهده آخرین لاگ های پس از واپسین ورودتون به سیستم
journalctl -b -1
برای مشاهده لیست بوت هایی که به سیستم انجام دادین:
journalctl —list-boots
برای مشاهده لاگ ها در محدوده زمانی خاص:
journalctl --since "2015-01-10" --until "2015-01-11 03:00"
یکم خودمونی ترش😁:
journalctl --since yesterday
لاگ خونی بر اساس یونیت های systemd:
برای اینکه مثلا بخواید کل لاگ های مربوط به nginx رو در بیارین:
journalctl -u nginx.service
دستور بالا با دادن پارامتر زمانی دلخواه:
journalctl -u nginx.service --since today
لاگ گیری از فعالیت های کرنل:
journalctl -k
بر اساس مسیج های حیاتی لاگ ها:
journalctl -p emerg -b
*نکته:مسیج ها در سیستم به چند دسته تقسیم میشن:(براساس حساسیت نوع پیغام)
0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug
که دستور بالا به ما فقط لاگ های فوق حساس رو نشون میده.ن
و در نهایت برای مشاهده n لاگ واپسین:
journalctl -n 20