الفصل : 12
الجزء : 3
العنوان : ال Redundancy في Windows Server 2022
تهيئة Storage Replica
لقد أنشأت خادمين جديدين في مختبري، بنية تحويلهما إلى خوادم ملفات زائدة عبر SR. هذه الخوادم تسمى FS01 وFS02 وتم ضمهما إلى المجال الخاص بي، وهناك بعض الأمور الهامة التي قمت بها معهم:
- قمت بإرفاق قرص جديد ليتم استخدامه لتخزين البيانات. يعمل Windows على قرص افتراضي عادي على الخادم، ولكنني أضفت قرصًا ثانيًا سيكون مخصصًا للتخزين. الجزء المهم هنا هو أن قرص البيانات يجب أن يتم تهيئته باستخدام GPT.
- قمت بإنشاء وحدة تخزين لتحتوي على البيانات. تم تسمية هذه الوحدة في Windows بـ S: drive ومرة أخرى، أنا فقط أتأكد من أن وحدة التخزين هذه توجد على قرص مهيأ بـ GPT.
- قمت بإنشاء وحدة تخزين منفصلة لتحتوي على بيانات سجلات SR. عند إنشاء مجموعة SR لاحقًا، سنحتاج إلى تحديد موقع لحفظ سجلات SR، ومن الأسهل القيام بذلك على حرف محرك خاص بها. لقد سميت محرك الأقراص L:. أيضًا، يوجد على قرص البيانات المهيأ بـ GPT. يجب أن تكون وحدة التخزين المستخدمة للسجلات بحد أدنى 9GB.
- قمت بتثبيت ميزة Storage Replica داخل Windows على كلا الخادمين.
تهيئة الأقراص كـ GPT
إذا لم تكن مألوفًا بالعملية المذكورة أعلاه لتهيئة قرص البيانات الجديد كـ GPT، دعونا نغطي ذلك لدقيقة. بعد إرفاق قرص جديد إلى خادمك، انقر بزر الماوس الأيمن على زر البدء وتوجه إلى إدارة الأقراص. يجب أن يتعرف هذا الأداة تلقائيًا على القرص الجديد ويسألك ما إذا كنت تريد تهيئته باستخدام MBR أو GPT. تأكد من اختيار GPT هنا:
اختبار جاهزية Storage Replica
لدينا الآن خادما ملفات، كل منهما يحتوي على قرص بيانات GPT جديد يحتوي على وحدتين تخزين جديدتين. واحدة ستستخدم لتخزين بيانات SR، والأخرى لسجلات SR. إليك نظرة سريعة على وحدات التخزين التي لدي. تم إعدادها بنفس الطريقة تمامًا على كلا الخادمين:
في هذه المرحلة، يمكننا المضي قدمًا في إنشاء بيئة Storage Replica، ولأن هذه خوادم جديدة تمامًا مع تكوينات متطابقة، فمن المرجح أن تعمل. ومع ذلك، في كثير من الأحيان، ستقوم بتكوين SR على خوادم كانت تعمل في الإنتاج لفترة من الزمن، أو على الأقل على خادم الملفات الرئيسي حيث ستكون بيانات المصدر موجودة. معرفة ما إذا كانت SR ستعمل بنجاح سيكون معرفة مريحة.
لحسن الحظ، هناك عملية اختبار يمكن أن يقوم بها SR قبل تنفيذ تكويناتك. باستخدام PowerShell، دعونا نصدر أمرًا طويلاً من خادمنا الأساسي FS01. الأمر التالي هو الذي أشغله. بالطبع، سيتعين عليك تعديله ليناسب أسماء الخوادم وحروف وحدات التخزين الخاصة بك. كما ترى في نهاية الأمر، أقوم بتحديد أن يتم وضع النتيجة داخل مجلد C:\SR_TEST، لذا تأكد من وجود هذا المجلد على خادمك:
Test-SRTopology -SourceComputerName FS01 -SourceVolumeName S: -SourceLogVolumeName L: -DestinationComputerName FS02 -DestinationVolumeName S: -DestinationLogVolumeName L: -DurationInMinutes 10 -ResultPath C:\SR_TEST\
سيقوم هذا الاختبار بجمع معلومات عن الخوادم ووحدات التخزين وتشغيل بعض نقلات البيانات التجريبية في الخلفية لمدة 10 دقائق (كما هو محدد في الأمر). بعد الانتهاء، ستجد ملف النتائج داخل C:\SR_TEST والذي يجب أن يفتح في متصفح الويب ليظهر لك جميع أنواع المعلومات الناتجة. سيتم تفصيل أي مشاكل في البيئة التي قد تعوق عمل SR هنا حتى تتمكن من حل تلك المشاكل:
ستلاحظ في الشكل أن لدي بعض التحذيرات في مختبري، والتي قمت بها عمدًا حتى تحصل على تصور لما تبدو عليه التحذيرات. لم أفتح حركة مرور ICMP بين هذه الخوادم، لذا تلقيت تحذيرًا بشأن عدم القدرة على إجراء اختبار زمن انتقال الشبكة. كما تظهر بعض تحذيرات الذاكرة الفيزيائية. في مجموعة Storage Replica، يحتاج كل خادم إلى 2GB من ذاكرة الوصول العشوائي (RAM)
ليعمل SR بشكل صحيح، وهو ما قمت بتخصيصه للأجهزة الافتراضية الخاصة بي. بينما يتطلب 2GB، يوصى بـ 4GB، والتحذيرات ببساطة تُعلمني بذلك. في بيئة الإنتاج، لن تشغل خادم ملفات بذاكرة 4GB فقط، لذلك من المحتمل ألا تواجه هذه التحذيرات أثناء التنفيذ الفعلي.
تهيئة Storage Replica
الآن وبعد أن تم إعداد خوادمنا واختبارها، حان الوقت لبناء الشيء الحقيقي! نظرًا لأننا استوفينا جميع المتطلبات الأساسية وبنينا الخوادم مع مراعاة SR، فإن كل ما يتطلبه الأمر هو أمر PowerShell واحد لبدء شراكة Storage Replica. سأقوم بإدراج الأمر أدناه، وهو واضح إلى حد ما. الأجزاء الوحيدة التي قد تكون غير مألوفة قليلاً هي SourceRGName وDestinationRGName. يشير "RG" إلى "Replication Group" وهو ببساطة اسم يجب أن تحدده لمجموعة التكرار على كل خادم:
New-SRPartnership -SourceComputerName FS01 -SourceRGName RepGroup1 -SourceVolumeName S: -SourceLogVolumeName L: -DestinationComputerName FS02 -DestinationRGName RepGroup2 -DestinationVolumeName S: -DestinationLogVolumeName L:
ها هو! تم تكوين Storage Replica مع اعتبار محرك S: الخاص بـ FS01 هو التخزين الأساسي، الذي يتم تكراره تلقائيًا وبشكل متزامن إلى محرك S: الخاص بـ FS02. اعتمادًا على أداء المواصفات الشبكية، يمكن أن تستغرق عملية المزامنة الأولية بين وحدات التخزين بعض الوقت، وخلال ذلك سترى ReplicationState = InitialBlockCopy في نتائج الأمر Get-SRGroup. بمجرد اكتمال المزامنة الأولية، سيتغير هذا الحقل إلى ReplicationState = ContinuouslyReplicating. سيتم تكرار أي بيانات يتم تخزينها على محرك S: الخاص بـ FS01 تلقائيًا إلى محرك S: الخاص بـ FS02.
تحويل الخادم الأساسي إلى FS02
بعد التجول في خوادم الملفات، ستلاحظ أنه يمكنك رؤية البيانات على محرك S: الخاص بـ FS01، ولكن إذا حاولت استعراض محرك S: الخاص بـ FS02، ستواجه رسالة خطأ – "S:\ is not accessible. The device is not ready." هذا متعمد. لا يمكنك استعراض ورؤية البيانات على خادم SR الوجهة، حتى تقوم بتشغيل أمر آخر لجعله الأساسي، مثلما يحدث في حالة استعادة الكوارث. لإثبات أن SR يعمل بالفعل، دعنا نتبع تلك الخطوة للتأكد من أن البيانات تتكرر تلقائيًا من FS01 إلى FS02.
لقد أنشأت بعض ملفات النصوص التجريبية على محرك S: الخاص بـ FS01، لكنني غير قادر على التحقق من وجودها على FS02. لنفترض أن FS01 قد تعطل أو يواجه مشكلة ما، وأحتاج إلى جعل FS02 خادم الملفات الأساسي الجديد. كل ما أحتاجه هو تشغيل الأمر PowerShell التالي على FS02 لتحويل الأدوار، وجعل FS02 الشريك SR الأساسي الجديد:
Set-SRPartnership -NewSourceComputerName FS02 -SourceRGName RepGroup2 -DestinationComputerName FS01 -DestinationRGName RepGroup1
بمجرد تشغيل هذا الأمر، يمكنني الآن رؤية واستعراض البيانات على محرك S: الخاص بـ FS02، مما يعني أنه الآن عضو SR الأساسي، ويثبت لي أيضًا أن SR كان يعمل في المقام الأول.
وكما هو متوقع، إذا حاولت فتح واستعراض محرك S: على FS01، فسأتلقى الآن رسالة الخطأ على تلك العقدة بدلاً من ذلك.
ال Storage Spaces Direct (S2D)
ال S2D هي تقنية clustering، لكنني أدرجها هنا بشكل منفصل عن clustering الفشل التلقائي العام لأن S2D هي جزء أساسي من مركز البيانات المعرف بالبرمجيات (SDDC) وقد حظيت بتركيز كبير على التحسينات على مدى السنوات القليلة الماضية حتى أنها أصبحت في فئة خاصة بها. كمقدمة، لن أتمكن بأي حال من تغطية جميع جوانب Storage Spaces Direct في هذا الفصل؛ فهي تستحق كتابًا خاصًا بها. هناك روابط في نهاية هذا القسم ستنقلك إلى مجموعات من الوثائق المصاحبة لـ S2D.
بشكل مختصر، S2D هي طريقة لبناء منصة تخزين مركزية شبكية فعالة للغاية وذات تكرار عالي بالكامل من Windows Server. في حين أنها تخدم نفس الغرض العام (تخزين الملفات) مثل جهاز NAS أو SAN التقليدي، تأخذ S2D نهجًا مختلفًا تمامًا في أنها لا تتطلب أجهزة متخصصة، ولا كابلات خاصة أو اتصال بين عقد كلستر S2D.
لبناء S2D، كل ما تحتاجه هو خوادم Windows – كلما كانت أسرع كان ذلك أفضل – ولكنها يمكن أن تكون خوادم عادية يومية. تحتاج هذه الخوادم إلى أن تكون نسخة Datacenter Edition من Windows Server، لكن يمكنك تشغيل S2D على عقد Server Core أو Desktop Experience. يجب أن تكون هذه الخوادم متصلة عبر الشبكة، وتحتاج تلك الشبكة إلى أن تكون جادة بما يكفي ليعمل S2D بشكل صحيح. ستحتاج إلى عرض نطاق ترددي عالي وزمن انتقال منخفض بين الخوادم لتحقيق النجاح – الحد الأدنى الذي نتحدث عنه هنا هو 10Gb. بمجرد تشغيل هذه الخوادم واتصالها، يمكنك استخدام تقنيات clustering أو WAC لربط هذه الخوادم معًا في مجموعات S2D.
ال S2D هي جزء من القصة الشاملة للبنية التحتية المتقاربة (HCI) وهي طريقة رائعة لتوفير تخزين سريع ومحمٍ لأي شيء، خاصةً للأحمال مثل مجموعات خوادم Hyper-V. كما تعلم بالفعل، عند بناء كلستر خادم Hyper-V، يجب أن يكون لدى عقد الكلستر الوصول إلى تخزين مشترك حيث ستقيم ملفات الأقراص الصلبة لـ VMs. S2D هي أفضل طريقة لتوفير هذا التخزين المركزي.
ال S2D ستجمع محركات الأقراص الصلبة داخل عقد كلستر S2D وتجمع كل مساحتها معًا في مجموعات تخزين معرفة بالبرمجيات. يتم تكوين هذه مجموعات التخزين بقدرات التخزين المؤقت وحتى التحمل المدمج للأعطال. من الواضح أنك لن ترغب في أن تتسبب عقدة S2D واحدة أو حتى محرك أقراص صلبة واحد في تعطل حل S2D الخاص بك، وبالطبع، لا تريد Microsoft أن يحدث ذلك أيضًا. لذا عند تجميع الخوادم وكل محركات الأقراص الخاصة بها معًا في مجموعات التخزين الكبيرة هذه لـ S2D، يتم تكوينها تلقائيًا بالتوازي بين تلك المحركات بحيث لا يؤدي تعطل مكونات معينة إلى فقدان البيانات أو حتى تباطؤ النظام.
ال S2D هي أفضل منصة تخزين لكل من SOFS وHyper-V clusters.
على الرغم من أن الإصدارات المبكرة من S2D تم تكوينها في الغالب من خلال PowerShell (مما يعني للأسف أن الكثير من المسؤولين لم يجربوها بعد)، إلا أن الإصدار الحالي من Windows Admin Center يتضمن
الخيارات المضمنة لتكوين بيئة S2D:
جديد في Server 2022 و2019
تم إجراء العديد من التغييرات الرائعة على Storage Spaces Direct على مدى السنوات القليلة الماضية، من خلال إصدارات Windows Server 2019 و2022. في المستقبل، تركز Microsoft بشكل أساسي على تغييرات S2D للوصول إلى Azure Stack HCI، حيث تتوقع أن معظم الشركات ستستخدم تلك التقنية لدعم Storage Spaces Direct. عندما يتم تقديم ميزات جديدة إلى Azure Stack HCI، يتم نقل بعضها أو جميعها إلى الإصدار الأخير من Windows Server أيضًا.
تحديدًا لـ Windows Server 2022، أعرف فقط عن تحسينين تم إجراؤهما في هذا المجال:
-ال **Adjustable Storage Repair Speed**: قدرة S2D على إصلاح نسخ البيانات بين الخوادم ليست شيئًا جديدًا، ولكن بدءًا من Windows Server 2022، لديك الآن خيارات للتحكم في مقدار موارد العمل المخصصة لهذه المهمة.
- ال**Storage Spaces Tiering**: كما تعلم بالفعل، يدور Storage Spaces Direct حول جمع التخزين من عدة خوادم ودمجها جميعًا معًا. خطوة للخلف قليلاً من هذه الفكرة، ربما سمعت عن Storage Spaces، وهي تقنية مشابهة ولكنها مختلفة تُستخدم على أساس كل خادم. يستخدم Storage Spaces البرامج لجمع محركات أقراص متعددة في خادم واحد لإنشاء مساحة تخزين أكبر قابلة للاستخدام، وهذه الميزة الجديدة هي تحديدًا لـ Storage Spaces. لدينا الآن خيار تصنيف التخزين، مما يتيح لنا استخدام محركات أقراص SSD للتخزين المؤقت.
كانت هناك تحسينات أخرى في S2D خلال إصدار Windows Server 2019، ولا تزال ذات صلة اليوم:
- **تحسين استخدام ReFS**: لدينا الآن وظائف إلغاء التكرار والضغط على وحدات ReFS التي تستضيفها S2D.
- ال**USB witness**: كما ناقشنا سابقًا. عند استخدام شاهد لمراقبة كلستر S2D يتكون من عقدتين فقط، يمكنك الآن استخدام مفتاح USB موصول بمعدات الشبكة، بدلاً من تشغيل خادم ثالث لهذا الغرض.
- ال**WAC**: يتضمن WAC الآن أدوات ووظائف لتعريف وإدارة كلسترات S2D. سيجعل هذا التبني أسهل للأشخاص الذين ليسوا على دراية كبيرة بـ PowerShell.
- **تحسين القدرة**: يمكننا الآن استضافة أربعة بيتابايت لكل كلستر، مقارنة بواحد بيتابايت في Server 2016. ومع ذلك، يُوصى بالحفاظ على حد أقصى 400TB لكل خادم داخل الكلستر.
- **تحسين السرعة**: في حين كان S2D سريعًا منذ الإصدار الأول، كان لدينا بعض تحسينات الكفاءة في Server 2019. في مؤتمر Ignite لهذا العام، عرضت Microsoft كلستر S2D مكونًا من 8 عقدة قادرًا على تحقيق 13,000,000 IOPS.
ملخص
يعد التكرار (redundancy) مكونًا حاسمًا في الطريقة التي نخطط بها للبنية التحتية ونبني الخوادم في عالم اليوم. يحتوي Windows Server 2022 على قدرات قوية مدمجة يمكنك استخدامها في بيئاتك الخاصة، بدءًا من اليوم! آمل أن تحصل من خلال استيعاب المزيد من المعلومات حول كل من NLB وclustering الفشل التلقائي، على القدرة على توسيع إمكانيات مؤسستك من خلال استخدام هذه التقنيات ودفع حدود وقت تشغيل الخدمة إلى أقصى حد.
حتى بالنسبة للشركات الصغيرة والمتوسطة الحجم، هناك بعض خيارات التكرار الرائعة في Windows Server، مما يجعلها ممكنة مع مجموعة محدودة من الخوادم. يمكنك استخدام Storage Replica لاستبدال العديد من الخيارات الأخرى الموجودة في هذه البيئات، مما يوفر لك خوادم ملفات متكررة بسهولة وسرعة. لأي مؤسسة على مستوى الشركات لم تختبر بعد الإمكانيات مع S2D، ما الذي يمنعك؟ لنأخذ الأمور بجدية بشأن التكرار للبنية التحتية لـ Hyper-V الخاصة بك. ستغير HCI الطريقة التي تعمل بها وتمنحك راحة البال التي لم تكن تعتقد أنها ممكنة في عالم يسعى لتحقيق 99.999% من وقت التشغيل.
النهاية
نكون هنا انتهينا من الفصل 12 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
