همچنین با افزایش تعداد هاست ها و ماشین های مجازی کار با این ساختار مجازی که رشدی هندسی دارد به چالش بزرگتری تبدیل می شود.
سخت افزار بیشتر، وابستگی متقابل را افزایش می دهد؛ زیرا ماشین های بیشتر، سخت افزار بیشتری نیاز دارند. تولید ماشین های مجازی بیشتر نتیجه فعالیت های تجاری بیشتر است. در نتیجه نگهداری و مدیریت بالاترین سطح از سرورهای مختلف و بهترین عملکرد آنها سریعاً به فعالیتی تبدیل می شود که هیچ انسان غیر مسلحی نخواهد توانست آنرا انجام دهد.
بر خلاف تصور شما، مجازی سازی DCها فعالیتی نیست که به آرامی صورت پذیرد. در واقع زمانی که مجازی سازی فواید زیادی را ارائه می کند، در مقابل ریسک این مسئله که مجازی سازی DCها هوشمندانه نبوده است نیز اضافه می شود. خوشبختانه، امروزه صنعت در حال پذیرفتن مجموعه ای از پیشنهادات هوشمندانه که سلامت و امنیت DCهای مجازی را تضمین می کنند، می باشد. اگر شما مجازی سازی برای Active Directory در یک DC را در نظر دارید، یا حتی هم اکنون آن را به صورت مجازی در اختیار دارید، این 12 نکته مهم را از دست ندهید. غفلت از هر نکته می تواند کل ساختار محاسباتی شما را نابود کند.
1. هرگز Pause ، Clone و Snapshot انجام ندهید، مگر …
__________________________________________________
در وهله اول به نظر می رسد مجازی سازی طیف گسترده ای از قابلیت های جدید را برای سرورهای مجازی فراهم می سازد. پس از مجازی سازی وضعیت سرور علاوه بر روشن و خاموش می تواند در حالت Pause هم قرار بگیرد. همچنین برای حفاظت از اطلاعات دیسک های سرور می توان Snapshot و یا Clone تهیه کرد.
قابلیت های Cloning ،Pausing و Snapshotting توابعی از پلتفرم مجازی است که باعث افزایش توانایی VMها می شود. این قابلیت ها می توانند تاکتیک های بسیار عالی برای راهکارهای مدیریتی انواع سرورهای مجازی باشند. اما استفاده از هر یک از این قابلیت ها برای یک DC هرگز توصیه نمی شود.
بازگشت به یک Snapshot از ماشین مجازی DC باعث می شود که سرور و Database آن به حالت قبل برگردد که این حالت هرگز در طراحی Replication در نظر گرفته نشده است. مشکلاتReplication ،USN Rollback و Database corruption تعداد کمی از اتفاقاتی است که ممکن است رخ دهد. مشکلاتی از این دست نیز می تواند وقتی که DC برای مدت زیادی در حالت Pause قرار بگیرد، رخ بدهد.
Cloning دیسک های DC مشکلات زیاد دیگری را بوجود می آورد و باید همواره از آن اجتناب نمود. وقتی یک DC متوجه می شود که Signature دیسکش تغییر کرده (این حالت زمان Cloning می تواند اتفاق بیافتد) DC خودش را از عملیاتReplication جدا می کند. DC ممکن است کارش را ادامه دهد اما DCهای دیگر با آن Replicate انجام نمی دهند. با گذشت زمان این حالت یک واگرایی بین محتوای DC ایزوله شده با دیگر DCها ایجاد می کند. یوزرهایی که Account آنها Delete شده ممکن است هنوز بتوانند LogOn کنند و یا Accountهایی که جدیداً ساخته شده است ممکن است با خطاهای غیر قابل پیش بینی مواجه شوند. برای جلوگیری از بوجود آمدن چنین مشکلاتی باید به طور کامل از Clone کردن DC اجتناب کرد.
راهنمایی در مورد “Never Snapshot” دارای یک نکته مهم است. برخی از راه حل های محافظت از داده می توانند با انجام Snapshot همه چیز را متوقف کنند. این توقف، جلوی خرابی دیتا، که بدون کمک گرفتن از Snapshot Hypervisor رخ می دهد، را می گیرد. بنابراین هرگز Snapshot نگیرید مگر از VMهایی که از چنین برنامه های محافظتی استفاده می کنند.
2. DCها نیاز به قابلیت VM High Availability دارند
______________________________________________
در محیط مجازی، در دسترس نگه داشتن یک Active Directory توسط DC از ویژگی های بارز High Availability است. در Database Applicationها اغلب از شیوه Multi-Master Replication برای در دسترس نگه داشتن سرویس ها استفاده نمی شود.
Active Directory به تنهایی سرویسی با انعطاف پذیری بالا و قابل توجه است. با توجه به اینکه هر بخش از ساختار ویندوز نیاز به احراز هویت توسط سرویس Active Directory دارد، در نتیجه این سرویس باید همیشه در دسترس بوده و بدون وقفه سرویس دهی کند.
انتظار می رود با وجود قابلیت High Availability در زیر محیط های مجازی،DC ها تقریباً همیشه در حال سرویس دهی باشند. Active Directory خودش تا حد امکان، نوشتن بر روی حافظه نهان دیسک و فایل های گزارش گیری را غیرفعال می کند. این عمل در صورت از کار افتادن ناگهانیActive Directory کمک شایانی به حفظ جامعیت و یکپارچگی داده ها می کند.
جلوگیری از قطع برق و از دسترس خارج شدن DCها نیز باید در اولویت باشد. هرDC مجازی شده باید بوسیله یک محیط مجازی با قابلیتHigh-Availability میزبانی شود. در مجازی سازی، بوسیله کلاستربندی هاست های موجود محیطی فراهم می گردد، تا اگر به هر دلیلی یکی از هاست ها از دسترس خارج شد سریعاً ماشین ها و سرویس های آن به یک هاست دیگر منتقل وDC در کمترین زمان ممکن مجدداً به مدار برگشته و سرویس دهی کند. تصمیم به مجازی سازی یکDC بر روی هاست و زیرساختی که قابلیت High Availability ندارد روش مناسبی نمی باشد.
3. عدم تهیه یکسان نسخه های مختلف Backup
__________________________________________
در زیرساخت مجازی، Snapshotting وCloning عمل هایی هستند که هرگز نباید در DCها مبادرت به استفاده از آنها کرد. کلمات Snapshot و Clone گاهی اوقات نیز معانی دیگری خارج از مبحث مجازی سازی دارند، مانند بعضی از موارد موجود درBackup Solution ها.
حتی سرویس Volume Shadow Copy مایکروسافت از کلمات و عباراتی مشابه برای توصیف پروسه Backup And Restore استفاده می کند؛ که در حقیقت ایده ایی مناسب برای تهیه Backup از DC می باشد.
به همین علت در این متن، سومین نکته فراگیری انواع روش های تهیه Backup ازDC را پیشنهاد می دهد. راهکار تهیه نسخه Backupای که شما نیاز دارید، راهکاریست که بتواند داده های ضروری مورد نیاز شما را سریعاً و به صورت Imaged-Based و Block-Level جمع آوری کند. انجام این کار حفاظت مستمر از داده ها را در حالیکه در معرض طیف گسترده ای از بازیابی موردی، از آیتم های مختلف می باشند، فراهم می کند.
شما به صورت مجزا ابزار اختصاصی پشتیبان گیری مایکروسافت را در اختیار نخواهید داشت. ابزارهای مایکروسافت برای تهیه نسخه پشتیبان ازActive Directory به صورتی کاربر پسند طراحی شده اند. بازیابی یک هدف، موضوع یا شی به صورت موردی کاری مشکل می باشد. بازیابی کل DC نیز پروسه ای چندین مرحله ای و حساس می باشد. تلاش برای احیا و بازیابی یک Forest از کار افتاده کاریست که حتی مدیران با تجربه IT نیز نخواهند توانست بدون کمک آنرا با موفقیت انجام دهند.
اتخاذ یک روش مناسب شما را قادر خواهد ساخت تا بتوانید هر موضوع یا شی، سرور یا یک Forest را به هر بازه زمانی مورد نیاز خود بازیابی کنید. این بازه زمانی ممکن است 15 دقیقه یا یک روز قبل باشد، که بستگی به نیاز و هدف شما از بازیابی دارد.
4. جلوگیری از عدم تطابق زمانی
____________________________
همزمان نگه داشتن ساعت ها در یک سرور فیزیکی کار چندان سختی نمی باشد. این ساعت یکبار تنظیم شده و برای مدت طولانی سرویس خواهد داد. اما این مسئله در محیط های مجازی صادق نیست. زیرا عدم تطابق زمانی بر اساس یک الگوی بی قاعده و نامنظم اتفاق خواهد افتاد و نیاز به توجه دائمی دارد.
عدم تطابق زمانی در ماشین های مجازی می تواند با نصب ابزار مناسب زیرساخت مجازی و یا همزمان کردن ساعت ها با یک منبع خارجی رفع و مدیریت گردد. بنابراین یکی از روش ها را به دلخواه انتخاب و در هرDC مجازی که ایجاد می کنید از آن استفاده کنید. این موضوع که کدام روش را انتخاب می کنید اهمیتی ندارد، فقط باید توجه کافی به تطابق زمانی ساعت DC داشته باشید. عدم تطابق زمانی کلاینت ها باDC باید کمتر از 5 دقیقه باشد، در غیر اینصورت DC به درخواست های کلاینت ها پاسخ نخواهد داد.
5. عدم اختصاص منابع بیشتر از نیاز به ماشین های مجازی
________________________________________________
هنگامی که متخصصان زمینه IT یک DC را بر روی یک سرور فیزیکی راه اندازی می کنند؛ معمولاً از یک پیکربندی رایج سخت افزاری یعنی “یک CPU دو هسته ای و 4 گیگابایت RAM” که بین تمام مدیران شبکه مرسوم است، استفاده می کنند.
این سطح حافظه و قدرت پردازشی، برای سرویس دهی یک DC بر روی یک سرور فیزیکی کاملاً منطقی به نظر می رسد. تفاوت قیمت بین حافظه های 1 و 4 گیگابایتی معمولاً در مقایسه با زمانی که یک تکنسین صرف محاسبه مقادیر صحیح آنها می کند از ارزش کمتری برخوردار می باشد.
محیط های مجازی بسیار متفاوت و متنوع می باشند؛ حتی با وجود منابعی با قابلیت های متعدد که بر روی سطح پایین سخت افزاری (Hypervisor) قابل نصب می باشند، ولی اختصاص این تعداد منابع فقط به یک ماشین مجازی، کار غیر ضروری و نامطلوب می باشد. منابع سخت افزاری بایستی به گونه ای مدیریت شوند که از واگذاری منابع بیش از نیاز یک ماشین به آن جلوگیری شود؛ تا از بروز مشکلاتی از قبیل Load Balancing با پیچیدگی بالا جلوگیری بعمل آید.
هیچگاه بیش از ظرفیت یک محیط مجازی از آن سرویس نگیرید؛ در واقع بهتر است با استفاده از “ابزارهای مدیریت” تعداد ماشین های مجازی مورد نیاز را محاسبه و از تخصیص چندین پردازشگر مجازی اجتناب شود.
6. اطمینان از صحت عملکرد Backupها
___________________________________
یک متخصص IT کم تجربه منحصراً تمرکز خود را بر روی فایل های Backup قرار می دهد در حالیکه یک فرد با تجربه می داند که هدف نهایی بازیابی داده ها می باشد. اگر بخواهیم بحث را بازتر کنیم بایستی به این نکته دقت شود که “روش های پشتیبان گیری” منجر به تهیه Backup هیچگاه بازیابی فایل ها را تضمین نمی کنند.
راه حل صحیح حافظت از داده های Active Directory تنها گرفتن Backup و بازیابی آنها نمی باشد. در واقع باید به دنبال راهکاری باشیم که هر Backup را پس از تهیه، بررسی و صحت عملکرد آن در مواقع مورد نیاز را تأیید کند. به این معنی که هر Object ، Domain Controller و یا Forest به صورت کامل و موفقیت آمیز قابل بازیابی می باشد.
7. پیاده سازی قوانین Anti-Affinity
________________________________
ماشین های مجازی به طور پیوسته حول محیط های مجازیشان در حرکت و تغییر هستند. واضح تر آن است که بگوییم تغییرات دائمی منابع سرور، موجب آن می شود که Load Balancing بطور پویا و بدون وقفه در جریان باشد. اما در صورتی که بیش از یک Host داشته باشیم و در صورت از کار افتادن یکی از Hostها کلیه سرویس ها می توانند به Host دیگر منتقل شوند. البته در زمانی که دو Domain Controller داریم؛ این قابلیت سبب می شود که دو Domain Controller بر روی یک Host قرار بگیرند که بایستی از این حالت جلوگیری شود.
هر سیستم عامل معمولاً به توابع خاصی که “قوانین Affinity” نامیده می شود، مجهز می باشد. این قوانین مدیر شبکه را قادر می سازد تا تصمیم بگیرد که کدام ماشین مجازی باید و کدام یک نباید به عنوان سرویس منتقل شده به یک Host دیگر به فعالیت خود ادامه دهد. در واقع قوانین Anti-Affinity برای Domain Controllerهای مجازی شده از اهمیت بالایی برخوردار هستند؛ زیرا این قانون سبب می شود تا از این موضوع اطمینان حاصل کنیم که در یک زیرساخت مجازی هیچگاه دو Domain Controller بر روی یک Host سرویس نخواهند داد. جداسازی Domain Controllerها و جلوگیری از سرویس دهی آن ها به صورت همزمان و بر روی یک Host به ما این اطمینان را خواهد داد که از دست دادن یکی از Hostها سبب از دسترس خارج شدن کامل سرویس Active Directory نخواهد شد.
8. جداسازی ترافیک مدیر شبکه از دیگر کاربران
_________________________________________
دکمه قرمز رنگی که بر روی ماشین مجازی قرار دارد و سبب خاموش شدن آن می شود، هیچ تفاوتی با دکمه خاموش/روشن شدن یک سرور فیزیکی ندارد. با زدن این دکمه، چه فیزیکی و چه مجازی، ماشین به همراه تمام سرویس هایی که بر روی آن می باشد، خاموش خواهد شد.
عملیاتی همچون خاموش/روشن کردن،Backup ،Snapshot و Clone بر روی کنسول مدیریتی هر سیستم عامل مجازی وجود دارد، البته بایستی به این نکته دقت شود که دسترسی کاربران معمولی به این گزینه ها باید محدود و کنترل شود. مثلاً در یک Datacenter برای محدودسازی دسترسی ها به اتاق سرور، درب ورودی را قفل می کنند که دقیقاً همچین اقدامی نیز باید در خصوص سطح دسترسی ها برای زیرساخت های مجازی صورت پذیرد. جداسازی ترافیک کاربران شبکه از ترافیکی که برای عملگرهای خاص محیط مجازی استفاده می شود از مواردی می باشد که کارکردی شبیه به قفل نمودن درب اتاق سرور خواهد داشت. بنابراین از گزینه های مهمی که بر روی یک ماشین مجازی می باشد و ممکن است به صورت تصادفی یا عمداً زده شوند به طور جدی باید محافظت کرد.
9. اولویت در بازگرداندن سریع Objectها
___________________________________
تا قبل از انتشار ویندوز سرور 2008 R2، قابلیت بازگرداندن Objectها به صورت موردی وجود نداشت. حتی بعد از انتشار آن، کار با Active Directory Recycle Bin به صورت یک چالش باقی ماند زیرا جمع آوری داده ها و بازگرداندن Objectهای حذف شده نیاز به استفاده از دستورات پیچیده Powershell داشت.
بالاخص زمانی که وقت کافی در اختیار نبوده و بایستی کار بازیابی به سرعت انجام گیرد، پیدا کردن Object صحیح جهت بازگرداندن نیز بسیار مشکل خواهد بود.
به همین دلیل است که در هر Domain Controller، چه مجازی و چه غیر مجازی، باید از روش هایی جهت حفاظت اطلاعات استفاده کرد که در جهت بازگرداندن سریع Objectها طراحی شده باشند. مجازی سازی می تواند در این زمینه کمک شایانی باشد. به عنوان مثال، هنگامی که در یک Domain Controller مشکلی پیش بیاید می توانیم با برگرداندن آنDomain Controller به یک نقطه امن قبلی، اطلاعات را بازگردانده و سپس بدون اینکه اثر مخربی بر روی زیرساخت مجازی بگذارد آن را حذف کنیم.
مسلماً پیدا کردن یک راه حل جهت گرفتن Backup از Active Directory و سپس بازگرداندن Objectهای حذف شده به صورت موردی در کمترین زمان و با صرف کمترین تلاش از مواردی می باشد که همیشه مد نظر یک مدیر شبکه بوده؛ تا بتواند بدین طریق تمام Objectهای حذف شده تصادفی توسط کاربر یا بروز هرگونه مشکل را بازگرداند.
10. مانیتور نمودن عملکرد ذخیره سازها
__________________________________
در اوایل کار مجازی سازی، دو گزینه پردازش و حافظه جزء مهمترین تنگناهایی بودند که به طور عمده بر عملکرد سیستم تأثیر گذار بودند. تعیین توان پردازش کافی برای هر ماشین مجازی جزء مواردی بود که توسط مدیر هر شبکه مجازی در اولویت قرار می گرفت.
اما امروزه ذخیره سازها به عنوان اساسی ترین منبع که سبب پایین آمدن کارآیی سیستم خواهند شد شناخته شده اند. اینگونه پایین آمدن کارآیی سیستم می تواند ناشی از پیکربندی غیر صحیح و یا ارتباطات نادرست باشد. هنگامی که Domain Controllerهای مجازی شده نیازی به ذخیره سازهایی با کارایی بالا ندارند، مانیتور نمودن IOPS (تعداد درخواست های خواندن و نوشتن در هر ثانیه) در مقابل ارتباطات ذخیره ساز جهت مدیریت کارآیی سیستم بسیار مهم است. حتی اگرچه Domain Controller شما به سریع ترین دیسک های دنیا نیاز نداشته باشد ولی کارآیی دیگر Hostها و ماشین های مجازی موجب ایجاد مشکلاتی برای شما خواهد شد. تنها با مانیتور نمودن رفتار ذخیره سازها می توانیم مشکلاتی از این قبیل را پیدا و درصدد حل آن ها برآییم.
11. استفاده محدود از سرور فیزیکی را فراموش نکنید
_______________________________________________
محیط مجازی شما می تواند حتی با مزایایی که مجازی سازی برای سرورها به ارمغان آورده است، یک Single Point Of Failure باشد. آسیب پذیری Hypervisor، وقفه در ذخیره سازی و استفاده نادرست از منابع، سناریوهایی هستند که می توانند موجب کاهش بازدهی و در نهایت از دسترس خارج شدن محیط مجازی شوند.
عدم دسترسی به Active Directory، زمانی که کل Active Directory شما روی زیرساخت مجازی از کار افتاده باشد، می تواند بسیار مشکل ساز باشد. اغلب، رفع این مشکل با راه اندازی مجدد سرویس های دایرکتوری آغاز می گردد. اگر این سرویس ها مجدد قابل دسترسی نباشند حل مشکل به طور قابل توجهی تبدیل به یک پروسه چالش برانگیز خواهد شد.
بازیابی و احیای یک محیط مجازی از کار افتاده در فاز عملیاتی نیاز به یک زیر ساخت مانند Active Directory دارد. بنابراین داشتن حداقل یک سرورDC به صورت فیزیکی، شما را مطمئن می سازد که Active Directory حتی در بدترین اتفاقات پیش آمده در محیط های مجازی قابل بازیابی بوده و در دسترس باقی خواهد ماند.
12. همیشه یک راهکار برای بازگشت از بحران داشته باشید.
________________________________________________
آمادگی برای تامین نیازها در بدترین حالات، بیشتر از یک راهکار برای بازگشت از بحران دارای اهمیت است. زیرا برای اجرای راه کار اصلی می بایست ابتدا نیازهای اجرایی آن برای عملی شدن را تامین کنیم. ترکیب ابزارهای مختلف برای پشتیبان گیری از Active Directory فقط بخشی از راهکار می باشند.
همچنین شما باید از این موضوع که ابزار شما عملیاتی بوده و قابلیت بازیابی و احیای سرورها و داده هایی که راهکار شما را به نتیجه می رسانند به طور منظم اطمینان حاصل نمائید.
این فقط شما نیستید که Backup تهیه می کنید. بلکه در واقع خود سیستم عامل ها نیز حالتی از Backup را بوسیله گرفتن یک کپی از داده های Active Directory شبیه سازی و ذخیره می کنند. اما Backupهای تهیه شده با این روش به آسانی قابل بازیابی نبوده؛ بنابراین یک راهکار عملیاتی به حساب نمی آیند.
راهکاری موثر خواهد بود که بتواند کل DC را در یک دقیقه و نه یک روز، بسرعت بازیابی و احیا کرده تا تجارت شما در کمترین زمان ممکن مجدداً آغاز بکار کند. جستجو برای یافتن یک راهکار که بتواند به صورت عملیاتی ماشین های مجازی را بدون تاخیر زیاد و بصورت فیزیکی بازیابی کند کمی زمان بر است. در آخر، نیاز اصلی شما سرویس دادن بدون وقفه‌یActive Directory می باشد. راهکار درست، سریعاً سرویس ها را راه اندازی کرده در حالیکه در پشت صحنه به آرامی بازیابی داده ها در حال انجام است.
مجازی سازی Domain Controller همراه با مراقبت؛
محافظت از داده های Domain Controller همراه با مراقبت بیشتر
اتخاذ تصمیم مجازی سازی یک Active Directory Domain Controller می تواند برای عملکرد بهتر Datacenter واقعاً هوشمندانه باشد، زیرا منجر به رهاسازی بخشی از منابع سخت افزاری سرور جهت انجام فعالیت ها و سرویس دهی توسط سرویس های دیگر خواهد شد. همچنین قابلیت های دیگری همچون High Availability و ویژگی مهاجرت به هر سرور مجازی اضافه خواهد شد. اما همانطور که مجازی سازی Domain Controllerها موجب راحت تر شدن این فعالیت ها می شود، ولی تنظیمات نادرست و ناآگاهانه مطمئناً نتیجه عکس خواهد داد. این 12 نکته اساسی سبب می شوند که شما با کمک یک طراحی و پیکربندی صحیح به سمت جلو حرکت کنید.
بخش اصلی طراحی مربوط به روش های صحیحی می باشد که بتوانیم محافظت از اطلاعات Active Directory را به نحو احسن انجام دهیم. به عنوان اساسی ترین موضوع در بحث Datacenter باید به این نکته توجه نمود که حفاظت از داده ها به دقت بسیار زیادی نیازمند است. آگاه باشید همانطور که چگونگی مجازی سازی Domain Controllerها برایمان اهمیت دارد، حفاظت از داده های آن نیز از اهمیت بالایی برخوردار می باشد.