الفصل : 12
الجزء : 1
العنوان : ال Redundancy في Windows Server 2022
ضرب ذلك في اثنين (Multiply that by two). هذه عبارة أسمعها طوال الوقت عند التخطيط لنشر الخوادم للعمل. بالتأكيد سمعتها أنت أيضًا. في أي وقت تطرح فيه تقنية جديدة، تريد أن تخطط لهذا الطرح بعناية فائقة. حدد ما هي الخوادم التي تحتاجها، وأين يجب وضعها، وكيف يجب تكوين الشبكة لهذه الأجهزة. بمجرد الانتهاء من التخطيط، اطلب اثنين من كل شيء، في حال تعطل أحدهم. نحن نعيش في عالم من التكنولوجيا المستمرة. انقطاع الخدمات غير مقبول، خصوصًا إذا كنا نستضيف خدمات سحابية أو سحابة خاصة. أي تطبيق أو خدمة يعتمد عليها مستخدمونا لإنجاز عملهم هي مهمة وتحتاج إلى تشغيل دائم 100%، أو قريب جدًا من ذلك. المشكلة مع التكرار (redundancy) هي أنه من السهل التحدث عن الأمر لكن من الصعب تنفيذه. ربما يومًا ما سنحظى بزر "اضغط هنا لجعل هذا الخادم متكررًا" السحري – لكن اليوم ليس هذا اليوم. نحتاج إلى فهم التقنيات المتاحة لنا التي تمكننا من توفير التكرار في أنظمتنا. ستقدم لنا هذا الفصل بعضًا من تلك التقنيات. يركز هذا الكتاب على Server 2022 المستخدم في المواقع المحلية، لذا فإن التقنيات التي نغطيها هي التي يمكنك استخدامها في مراكز البيانات المحلية لديك على خوادم حقيقية (مادية أو افتراضية) التي تكون مسؤولًا عن بنائها وتكوينها وصيانتها. نعم، السحابة يمكن أن توفر لنا بعض الخيارات السحرية للتوسع والتكرار، لكن هذه الأمور سهلة، وغالبًا لا نحتاج حتى إلى فهم كيفية عملها. عندما نستخدم خوادمنا داخل جدراننا الخاصة، كيف يمكننا إضافة بعض الموثوقية المتزايدة لأنظمتنا؟
سوف نغطي المواضيع التالية في هذا الفصل:
•ال Network Load Balancing (NLB)
• تكوين موقع ويب موزع التحميل
•ال Clustering التكرار
• طبقات التكرار
• إعداد كتلة التكرار
• التحسينات في التكرار في Windows Server 2022
• الStorage Replica (SR)
•ال Storage Spaces Direct (S2D)
ال Network Load Balancing (NLB)
غالبًا، عندما أسمع أشخاصًا يناقشون التكرار في خوادمهم، تتضمن المحادثة العديد من المرات التي يتم فيها ذكر كلمة "cluster"، مثل "إذا قمنا بإعداد cluster لتوفير التكرار لهذه الخوادم..." أو "موقعنا الرئيسي يعمل على cluster..." أو "هذا الوضع هو cluster حقيقي..." (انتظر، هذا شيء آخر تمامًا). بينما من الرائع أن هناك شكل من أشكال المرونة يتم استخدامه في الأنظمة التي تتعلق بها هذه المحادثات، غالبًا ما يكون الحال أن التكرار الفعلي ليس موجودًا في أي مكان. عندما نغلي تفاصيل كيفية تكوين أنظمتهم، نكتشف أن NLB هو الذي يقوم بهذا العمل لهم. سنناقش التكرار الفعلي في وقت لاحق في هذا الفصل، ولكن أولاً أردت أن أبدأ بالنهج الأكثر شيوعًا لجعل العديد من الخدمات متكررة. يقوم NLB بتوزيع الحركة على مستوى TCP/IP، مما يعني أن أنظمة تشغيل الخوادم نفسها ليست على دراية كاملة أو تعتمد على بعضها البعض، بل يتم توفير التكرار بدلاً من ذلك في طبقة الشبكة. يمكن أن يكون هذا مربكًا بشكل خاص – NLB مقابل التكرار – لأن مايكروسوفت في بعض الأحيان تشير إلى شيء ما كـ cluster عندما، في الواقع، تستخدم NLB لجعل تلك الاتصالات تحدث. الأمثلة الرئيسية هي تقنيات الوصول عن بعد من Microsoft. عندما يكون لديك خادمان أو أكثر للوصول عن بعد معًا في مجموعة، هناك مستندات TechNet وحتى أماكن داخل وحدة التحكم حيث يشار إليها كـ cluster. لكن لا يوجد تكرار فعلي يحدث هنا؛ التقنية الموجودة تحت الغطاء التي تجعل الاتصالات تتدفق إلى كلا العقدتين هي في الواقع Windows NLB.
ربما سمعت بعض الأسماء في سوق موازنات التحميل المادية – F5، Cisco، Kemp، Barracuda، والمزيد. توفر هذه الشركات أجهزة مخصصة أو أجهزة افتراضية يمكنها أخذ الحركة المتجهة نحو اسم معين أو وجهة معينة وتقسيم تلك الحركة بين خادمين أو أكثر. بينما هذا هو عمومًا أكثر الطرق موثوقية التي يمكنك من خلالها إنشاء NLB، إلا أنه أيضًا الأكثر تكلفة ويجعل البيئة الإجمالية أكثر تعقيدًا. إحدى الميزات التي تقدمها هذه الأجهزة التي لا يمكن لموازنة التحميل المضمنة في Windows NLB توفيرها هي إنهاء SSL، أو كما نسميها غالبًا تفريغ SSL. هذه الأجهزة المتخصصة قادرة على استقبال حركة مرور الويب SSL من أجهزة الكمبيوتر الخاصة بالمستخدمين وفك تشفير الحزم قبل إرسالها في طريقها إلى خادم الويب المناسب. بهذه الطريقة، يقوم خادم الويب نفسه بعمل أقل، حيث لا يحتاج إلى قضاء دورات CPU في تشفير وفك تشفير الحزم. من المهم لك أن تعرف أن حلول موازنات التحميل المادية موجودة، لكن اليوم، لن نتحدث عن موازنات التحميل المادية على الإطلاق، بل عن قدرات NLB التي توفرها مباشرة داخل Windows Server 2022.
ليس نفس الشيء مثل round-robin DNS
اكتشفت، على مر السنين، أن فكرة بعض الأشخاص عن NLB هي حقًا round-robin DNS. دعني أعطيك مثالًا على ذلك: لنفترض أن لديك موقعًا داخليًا يصل إليه جميع المستخدمين يوميًا. من المنطقي أنك تريد توفير بعض التكرار لهذا النظام، لذا تقوم بإعداد خادمين ويب، في حالة تعطل أحدهما. ومع ذلك، في حالة تعطل أحدهما، لا تريد أن تتطلب خطوات قطع يدوي للتبديل إلى الخادم الإضافي؛ تريد أن يحدث ذلك تلقائيًا. في DNS، من الممكن إنشاء سجلي host A يحملان نفس الاسم ولكنهما يشيران إلى عناوين IP مختلفة. إذا كان Server01 يعمل على 10.10.10.5 وServer02 يعمل على 10.10.10.6، يمكنك إنشاء سجلي DNS يحملان الاسم INTRANET، أحدهما يشير إلى 10.10.10.5 والآخر يشير إلى 10.10.10.6. هذا سيوفر round-robin DNS، لكنه ليس موازن تحميل حقيقي. بشكل أساسي، ما يحدث هنا هو أنه عندما تصل أجهزة الكمبيوتر العميلة إلى INTRANET، سيقوم DNS بإعطائهم أحد عناوين IP للاتصال به. DNS لا يهتم ما إذا كان ذلك الموقع قيد التشغيل بالفعل، فهو ببساطة يرد بعنوان IP. لذا حتى لو قمت بإعداد ذلك ويبدو أنه يعمل بلا عيوب لأنك ترى أن العملاء يتصلون بكلا الخادمين Server01 وServer02، كن على حذر. في حالة تعطل الخادم، سيكون لديك العديد من العملاء الذين لا يزالون يعملون، والعديد من العملاء الذين يحصلون فجأة على صفحة "لا يمكن عرض الصفحة" عندما يقرر DNS إرسالهم إلى عنوان IP الخاص بالخادم الذي أصبح الآن خارج الخدمة.
ال NLB أكثر ذكاءً من ذلك بكثير. عندما يتعطل أحد العقد في مجموعة NLB، سيتم توجيه الحركة المتجهة إلى عنوان IP المشترك فقط إلى العقدة التي لا تزال متصلة. سنرى هذا بأنفسنا قريبًا عندما نقوم بإعداد NLB على موقع ويب داخلي خاص بنا.
ما هي الأدوار التي يمكن أن تستخدم NLB؟
تم تصميم NLB بشكل أساسي للتطبيقات غير المرتبطة بالحالة (stateless applications)، بعبارة أخرى، التطبيقات التي لا تتطلب حالة ذاكرة طويلة الأجل أو حالة اتصال. في تطبيق غير مرتبط بالحالة، يمكن معالجة كل طلب مقدم من التطبيق من قِبل Server01 لفترة، ثم الانتقال إلى Server02 دون انقطاع في التطبيق. بعض التطبيقات تتعامل مع هذا بشكل جيد (مثل مواقع الويب)، وبعضها لا يتعامل معه جيدًا.
تستفيد خدمات الويب (IIS) بالتأكيد بشكل أكبر من التكرار الذي يوفره NLB. NLB سهل التكوين ويوفر تكرارًا كاملاً لمواقع الويب التي تشغلها على خوادم Windows الخاصة بك، دون تكبد أي تكاليف إضافية. يمكن أن يُستخدم NLB أيضًا لتعزيز خوادم FTP وجدران الحماية والخوادم الوكيلة.
دور آخر يتفاعل عادةً مع NLB هو دور الوصول عن بعد. على وجه التحديد، يمكن لـ DirectAccess استخدام NLB المدمج في Windows لتوفير بيئة الوصول عن بعد الخاصة بك بخوادم نقاط دخول متكررة. عند إعداد DirectAccess للاستفادة من موازنة التحميل، ليس من الواضح على الفور أنك تستخدم ميزة NLB المدمجة في نظام التشغيل لأنك تقوم بتكوين إعدادات موازنة التحميل من داخل وحدة إدارة الوصول عن بعد، بدلاً من وحدة NLB. عندما تمر عبر معالجات إدارة الوصول عن بعد لإنشاء موازنة التحميل، فإن وحدة التحكم عن بعد تقوم في الواقع بالوصول إلى آلية NLB داخل نظام التشغيل وتكوينها، بحيث تكون خوارزمياتها وآليات النقل هي القطع التي يستخدمها DirectAccess لتقسيم الحركة بين الخوادم المتعددة.
واحدة من أفضل الأجزاء حول استخدام NLB هي أنه يمكنك إجراء تغييرات على البيئة دون التأثير على العقد الموجودة. هل تريد إضافة خادم جديد إلى مجموعة NLB موجودة؟ لا مشكلة. أضفه دون أي توقف. هل تحتاج إلى إزالة خادم للصيانة؟ لا توجد مشاكل هنا أيضًا. يمكن إيقاف NLB على عقدة معينة، مما يسمح لعقدة واحدة بالخروج من المجموعة دون أي تأثير على بقية المجموعة أو الاتصالات التي يتم تقديمها عبر هذه العقد.
في الواقع، NLB يرتبط بـ NIC بشكل خاص، لذا يمكنك تشغيل أوضاع NLB مختلفة على NICs مختلفة داخل نفس الخادم. يمكنك إخبار NLB بالتوقف على NIC معين، مما يزيل هذا الخادم من المجموعة مؤقتًا. حتى أفضل من ذلك، إذا كان لديك بعض الوقت قبل أن تحتاج إلى إيقاف الخادم، يمكنك إصدار أمر drainstop بدلاً من التوقف الفوري. هذا يسمح بإنهاء الجلسات الشبكية الحالية التي تكون نشطة على هذا الخادم بشكل نظيف. لن تتدفق جلسات جديدة إلى NIC الذي قمت بإصدار أمر drainstop عليه، وستتبخر الجلسات القديمة بشكل طبيعي مع مرور الوقت. بمجرد إسقاط جميع الجلسات من ذلك الخادم، يمكنك سحبه وإنزاله للصيانة بدون أي انقطاع للمستخدم.
العناوين IP الافتراضية والمخصصة
من المهم أن نفهم كيف يستخدم NLB العناوين IP على الخوادم الخاصة بك. أولاً، يجب أن يكون لأي NIC على خادم سيكون جزءًا من مجموعة موازنة التحميل عنوان IP ثابت معين له. NLB لا يعمل مع عناوين DHCP. في عالم NLB، يُشار إلى عنوان IP الثابت على NIC كـ Dedicated IP Address (DIP). هذه العناوين DIPs فريدة لكل NIC، مما يعني بوضوح أن كل خادم لديه DIP خاص به. على سبيل المثال، في بيئتي، يعمل WEB1 على عنوان DIP هو 10.10.10.40، وخادم WEB2 يعمل على عنوان DIP هو 10.10.10.41.
كل خادم يستضيف نفس موقع الويب على عناوين DIPs الخاصة به. من المهم أن نفهم أنه عند إنشاء NLB بين هذين الخادمين، يجب أن نحتفظ بالعناوين DIPs الفردية على الصناديق، ولكننا سنقوم أيضًا بإنشاء عنوان IP جديد سيتم مشاركته بين الخادمين. هذا العنوان المشترك يُسمى Virtual IP Address (VIP). عند إعداد NLB قريبًا، سأستخدم عنوان IP 10.10.10.42 كـ VIP، والذي لم يُستخدم حتى الآن في شبكتي. هنا هو تخطيط سريع للعناوين IP التي ستُستخدم عند إعداد موقعي الإلكتروني المحمّل بالتوازن:
WEB1 DIP = 10.10.10.40
WEB2 DIP = 10.10.10.41
Shared VIP = 10.10.10.42
عند إنشاء سجل DNS لموقعي الإلكتروني intranet.contoso.local، الذي هو اسم موقعي الإلكتروني، سأقوم بإنشاء سجل host A واحد فقط، وسيشير إلى VIP 10.10.10.42.
أوضاع NLB
قريبًا، سنجد أنفسنا في التكوين الفعلي لموازنة التحميل وسنحتاج إلى اتخاذ بعض القرارات داخل تلك الواجهة. أحد القرارات الكبيرة هو ما هو وضع NLB الذي نريد استخدامه. يتم اختيار Unicast افتراضيًا وهو الطريقة التي أراها معظم الشركات تقوم بإعداد NLB بها، ربما لأنه الخيار الافتراضي ولم يفكروا في تغييره. دعونا نأخذ دقيقة لمناقشة كل الخيارات المتاحة، للتأكد من أنك يمكن أن تختار الخيار الأنسب لاحتياجاتك الشبكية.
ال Unicast
هنا، نبدأ في دخول صلب كيفية توزيع NLB الحزم بين المضيفين المختلفين. نظرًا لأننا لا نملك موازن تحميل مادي يستقبل الحركة أولاً ثم يقرر إلى أين يرسلها، كيف تقرر الخوادم الموزونة من يحصل على تيارات الحزم؟
للإجابة على هذا السؤال، نحتاج إلى التراجع قليلاً ومناقشة كيفية تدفق الحركة داخل شبكتك. عندما تفتح متصفح ويب على جهاز الكمبيوتر الخاص بك وتزور HTTP://WEB1، يحل DNS ذلك العنوان إلى 10.10.10.40، على سبيل المثال. عندما تصطدم الحركة بمفاتيحك وتحتاج إلى توجيهها إلى مكان ما، تحتاج المفاتيح إلى تحديد إلى أين يجب أن تذهب حركة المرور الموجهة إلى 10.10.10.40. قد تكون مألوفًا بفكرة عناوين MAC. لكل NIC عنوان MAC، وعندما تعين عنوان IP إلى NIC، يسجل عنوان MAC الخاص به وIP مع معدات الشبكة. يتم تخزين هذه العناوين MAC داخل جدول ARP، وهو جدول يقيم داخل معظم المفاتيح، والموجهات، وجدران الحماية.
عندما تم تعيين عنوان IP 10.10.10.40 إلى خادم WEB1، سجل عنوان MAC الخاص به الموافق لـ 10.10.10.40. عندما تحتاج الحركة إلى التدفق إلى WEB1، تدرك المفاتيح أن الحركة الموجهة إلى 10.10.10.40 يجب أن تذهب إلى عنوان MAC الخاص بهذا الـ NIC وتطلقها وفقًا لذلك.
لذا في عالم NLB، عندما ترسل حركة مرور إلى عنوان IP واحد يتم تقسيمه بين عدة NICs، كيف يتم معالجتها على مستوى MAC؟ الجواب مع NLB unicast هو أن عنوان MAC الفعلي لـ NIC يتم استبداله بعنوان MAC افتراضي، ويتم تعيين هذا MAC إلى جميع NICs داخل مجموعة NLB. هذا يتسبب في إرسال الحزم التي تتدفق إلى هذا العنوان MAC إلى جميع الـ NICs، وبالتالي إلى جميع الخوادم، في تلك المجموعة. إذا كنت تعتقد أن هذا يبدو مثل الكثير من حركة المرور غير الضرورية التي تتحرك حول المفاتيح، فأنت ستكون محقًا. NLB unicast يعني أنه عندما تكون الحزم موجهة إلى عنوان MAC الافتراضي لمجموعة، فإن تلك الحركة أساسًا ترتد عبر جميع المنافذ على المفتاح (أو على الأقل على الـ VLAN) قبل العثور على وجهتها والهبوط عليها.
أفضل جزء حول unicast هو أنه يعمل بدون الحاجة إلى إجراء أي تكوينات خاصة على المفاتيح أو معدات الشبكة في معظم الحالات. تقوم بإعداد تكوين NLB من داخل أدوات Windows Server، وهو يتولى الباقي. العيب في unicast هو أنه، لأن نفس عنوان MAC موجود على جميع العقد، فإنه يسبب بعض مشاكل الاتصال داخل العقدة. بعبارة أخرى، الخوادم المُمكَّنة لـ NLB ستواجه صعوبة في التواصل مع عناوين IP الخاصة ببعضها البعض. في كثير من الأحيان، هذا لا يهم حقًا، لأن WEB1 نادرًا ما يكون لديه سبب للتواصل مباشرة مع WEB2. لكن إذا كنت تحتاج حقًا إلى أن تتواصل تلك الخوادم الويب مع بعضها البعض باستمرار وبشكل موثوق، فإن الحل الأسهل هو تثبيت NIC منفصل على كل من تلك الخوادم واستخدام ذلك NIC للاتصالات داخل المجموعة، بينما تترك الـ NICs الأساسية مُكونة لحركة مرور NLB.
العيب الآخر لـ unicast هو أنه يمكن أن يخلق بعض الفيضانات في المفاتيح. المفاتيح غير قادرة على تعلم مسار دائم لعنوان MAC الافتراضي لأننا نحتاج إلى أن يتم تسليمها إلى جميع العقد في مجموعتنا. بما أن كل حزمة تتحرك إلى عنوان MAC الافتراضي يتم إرسالها عبر جميع قنوات المفتاح لكي تصل إلى جميع الـ NICs حيث تحتاج إلى أن يتم تسليمها، فإنها لديها القدرة على إغراق المفاتيح بهذه الفيضانات من حزم الشبكة. إذا كنت قلقًا حيال ذلك أو تتلقى شكاوى من الأشخاص المسؤولين عن شبكتك حول
الفيضانات في المفاتيح، قد ترغب في النظر في أحد أوضاع multicast لمجموعة NLB الخاصة بك.
طريقة بديلة للتحكم في فيضانات unicast هي أن تكون مبدعًا مع VLANs على المفاتيح الخاصة بك. إذا كنت تخطط لمجموعة خوادم NLB وتريد التأكد من أن حركة المرور الناتجة عن هذه المجموعة لن تؤثر على الأنظمة الأخرى في شبكتك، يمكنك بالتأكيد إنشاء VLAN صغير على المفاتيح الخاصة بك وتوصيل فقط الـ NICs المُستخدمة لـ NLB في تلك VLAN. بهذه الطريقة، عندما يحدث الفيض المتعمد، فإنه يضرب فقط ذلك العدد الصغير من المنافذ داخل VLAN الخاصة بك، بدلاً من تقسيم طريقه عبر المفتاح بأكمله.
ال Multicast
اختيار multicast كوضع لـ NLB يأتي مع بعض الفوائد وبعض الصداع. الإيجابية هي أنها تضيف عنوان MAC إضافي لكل NIC. كل عضو في NLB لديه بعد ذلك عنوانين MAC: الأصلي والذي أنشأه آلية NLB. هذا يعطي المفاتيح ومعدات الشبكة وظيفة أسهل في تعلم المسارات وإرسال الحركة إلى وجهاتها الصحيحة، دون فيض الحزم المفرط. للقيام بذلك، تحتاج إلى إخبار المفاتيح بأي عناوين MAC تحتاج إلى تلقي حركة NLB هذه؛ وإلا، ستسبب فيض في المفاتيح، تمامًا مثل unicast.
إخبار المفاتيح بأي MACs يجب أن يتم الاتصال بها يتم عن طريق تسجيل الدخول إلى مفاتيحك وإنشاء بعض إدخالات ARP الثابتة لاستيعاب هذا. لأي شركة لديها محترف شبكات مخصص، عادةً ما يكون بارعًا في معدات Cisco، سيكون هذا سهلًا. إذا لم تكن مألوفًا بتعديل جداول ARP وإضافة مسارات ثابتة، يمكن أن يكون من المزعج بعض الشيء الحصول على هذا بشكل صحيح. في النهاية، عادةً ما يكون multicast أفضل من unicast، لكنه يمكن أن يكون أكثر من صداع إداري. ميلي الشخصي لا يزال يميل نحو unicast، خاصةً في الشركات الصغيرة. لقد رأيته يستخدم في العديد من الشبكات المختلفة دون أي مشاكل، والذهاب مع unicast يعني أنه يمكننا ترك برمجة المفاتيح بمفردها.
ال Multicast IGMP
أفضل من ذلك، ولكن ليس دائمًا خيارًا، هو multicast مع Internet Group Management Protocol (IGMP). يساعد multicast IGMP حقًا في التخفيف من فيض المفاتيح، ولكنه يعمل فقط إذا كانت مفاتيحك تدعم IGMP snooping. هذا يعني أن المفتاح لديه القدرة على النظر داخل حزم multicast لتحديد أين يجب أن تذهب بالضبط. لذا حيث يخلق unicast بعض كمية الفيض في المفاتيح عن طريق التصميم، يمكن أن يساعد multicast في خفض تلك الكمية، وIGMP يمكن أن يتخلص منها تمامًا.
الوضع الذي تختاره لـ NLB يعتمد بشكل كبير على قدرات معدات الشبكة الخاصة بك. إذا كانت خوادمك تحتوي على NIC واحد فقط، حاول استخدام multicast أو ستواجه مشاكل داخل المجموعة. من ناحية أخرى، إذا كانت مفاتيحك وموجهاتك لا تدعم multicast، فلن يكون لديك خيار - unicast سيكون الخيار الوحيد لتكوين Windows NLB.
تكوين موقع ويب مُحمّل بالتوازن (Configuring a load-balanced website)
تحدثنا بما فيه الكفاية؛ حان الوقت لإعداد هذا لأنفسنا ومحاولة تجربته. لدي خادمان ويب يعملان في شبكة المختبر الخاصة بي، WEB1 و WEB2. كلاهما يستخدم IIS لاستضافة موقع ويب داخلي. هدفي هو توفير سجل DNS واحد لمستخدمي للوصول إليه، ولكن يتم تقسيم كل هذه الحركة بين الخادمين مع بعض موازنة التحميل الحقيقية. اتبع الخطوات التالية بينما نُعد هذا السيناريو.
تمكين NLB
أول الأشياء أولاً، نحتاج إلى التأكد من أن WEB1 وWEB2 مستعدين للقيام بـ NLB لأنه ليس مثبتًا بشكل افتراضي. NLB هو ميزة متاحة في Windows Server 2022، وتضيفها مثل أي دور أو ميزة أخرى، من خلال تشغيل معالج إضافة الأدوار والميزات. أضف هذه الميزة على جميع الخوادم التي تريد أن تكون جزءًا من مجموعة NLB.
تمكين تزوير عنوان MAC على الأجهزة الافتراضية (Enabling MAC address spoofing on VMs)
تذكر عندما تحدثنا عن NLB بتقنية Unicast وكيف يتم استبدال العنوان الفعلي لـ MAC الخاص بـ NIC بعنوان MAC افتراضي يستخدم للاتصالات ضمن مجموعة NLB؟ نعم، الأجهزة الافتراضية لا تحب ذلك. إذا كنت تقوم بتحميل التوازن على الخوادم الفيزيائية باستخدام بطاقات NIC الفيزيائية، يمكنك تجاوز هذا القسم. ولكن العديد منكم سيقوم بتشغيل خوادم ويب على الأجهزة الافتراضية. سواء كانت تستضيف على Hyper-V، VMware، أو أي تكنولوجيا افتراضية أخرى، هناك خيار إضافي في إعدادات الجهاز الافتراضي الذي يجب عليك اختياره لكي يتوافق جهازك الافتراضي مع هذا التغيير في عنوان MAC.
اسم هذا الإعداد سيكون شيء مثل "Enable MAC address spoofing"، على الرغم من أن الاسم المحدد لهذه الوظيفة قد يختلف اعتمادًا على التكنولوجيا الافتراضية التي تستخدمها. يجب أن يكون الإعداد عبارة عن مربع اختيار بسيط يتعين عليك تمكينه لجعل تزوير MAC يعمل بشكل صحيح. تأكد من القيام بذلك لجميع بطاقات NIC الافتراضية التي تخطط لاستخدامها مع NLB. تذكر أن هذا إعداد لكل NIC، وليس لكل جهاز افتراضي. إذا كان لديك عدة بطاقات NIC على جهاز افتراضي، قد تضطر إلى تحديد المربع لكل بطاقة NIC إذا كنت تخطط لاستخدامها جميعًا في التوازن.
اعتمادًا على مدى قدم برنامج الهايبرفايزر الخاص بك، قد تحتاج إلى إيقاف تشغيل الجهاز الافتراضي لإجراء هذا التغيير. بخلاف هذه النقطة، كل ما نحتاج إليه هو العثور على مربع الاختيار وتفعيله. نظرًا لأن كل ما أستخدمه يعتمد على تكنولوجيا Microsoft، فإنني أستخدم Hyper-V كمنصة للأجهزة الافتراضية في المختبر هنا. داخل Hyper-V، إذا قمت بالنقر بزر الماوس الأيمن على خادم WEB1 وتوجهت إلى إعدادات الجهاز الافتراضي، يمكنني بعد ذلك النقر على محول الشبكة لرؤية الأجزاء المختلفة التي يمكن تغييرها على بطاقة NIC الافتراضية لـ WEB1. في أحدث إصدارات Hyper-V، يتم سرد هذا الإعداد تحت خصائص NIC، داخل القسم المسمى "Advanced Features". وهناك هو، مربع الاختيار "Enable MAC address spoofing". ببساطة انقر على ذلك لتفعيله، وأنت جاهز:
إذا كان خيار "Enable MAC address spoofing" غير مفعل (مظللاً)، تذكر أن الجهاز الافتراضي قد يحتاج إلى إيقاف تشغيله تمامًا قبل ظهور الخيار. قم بإيقاف تشغيله، ثم افتح الإعدادات وألق نظرة أخرى. يجب أن يكون الخيار متاحًا الآن لتحديده.
تكوين NLB
لنلخص ما نحن عليه في هذه المرحلة. لدي خادمان ويب، WEB1 وWEB2، وكل منهما يحتوي حاليًا على عنوان IP واحد. كل خادم يحتوي على IIS مثبت عليه، والذي يستضيف موقع ويب واحد. لقد قمت بتمكين تزوير عنوان MAC على كل منهما (لأن هذه الخوادم هي أجهزة افتراضية)، وقد انتهيت للتو من تثبيت ميزة NLB على كل خادم ويب. لدينا الآن جميع الأجزاء والمكونات في مكانها لتكوين NLB وجعل حركة المرور على الويب تتوزع بين كلا الخادمين.
سأعمل من WEB1 لتكوين NLB في البداية. قم بتسجيل الدخول إلى هذا، وسترى أن لدينا أداة جديدة في قائمة الأدوات المتاحة داخل Server Manager، تسمى Network Load Balancing Manager. قم بفتح هذه الأداة. بمجرد فتح NLB Manager، انقر بزر الماوس الأيمن على Network Load Balancing Clusters واختر New Cluster، كما هو موضح في الشكل 12.3:
عند إنشاء مجموعة جديدة، من المهم ملاحظة أنه، حاليًا، لا توجد أجهزة في هذه المجموعة. حتى الخادم الذي نشغل عليه هذا الكونسول لم يتم إضافته تلقائيًا إلى المجموعة، وعلينا أن نتذكر إضافته يدويًا إلى هذه الشاشة. لذلك أولاً، سأقوم بكتابة اسم خادم WEB1 الخاص بي والنقر على Connect. بعد القيام بذلك، سيقوم NLB Manager باستجواب WEB1 للحصول على بطاقات NIC وسيعطيني قائمة ببطاقات NIC المتاحة التي يمكنني إعداد NLB عليها:
بما أن لدي بطاقة NIC واحدة فقط على هذا الخادم، سأتركها محددة وأنقر على Next. تعطيك لقطة الشاشة التالية الفرصة لإدخال عناوين IP إضافية على WEB1، ولكن بما أننا نشغل عنوان IP واحد فقط، سأترك هذه الشاشة كما هي، وأنقر على Next مرة أخرى.
الآن انتقلنا إلى نافذة تطلب منا إدخال عناوين IP الخاصة بالمجموعة. هذه هي عناوين VIP التي نعتزم استخدامها للتواصل مع مجموعة NLB هذه. كما ذكرت سابقًا، سيكون عنوان VIP الخاص بموقعي هو 10.10.10.42، لذلك سأضغط على زر Add... وأدخل عنوان IPv4 ذلك مع قناع الشبكة الفرعي الخاص به:
نقرة أخرى على زر Next، يمكننا الآن رؤية خيارنا لوضع عملية المجموعة الذي نريد تشغيله. اعتمادًا على تكوين شبكتك، اختر بين Unicast، Multicast، و IGMP multicast.
لقطة الشاشة التالية من معالج NLB تسمح لك بتكوين قواعد المنافذ. افتراضيًا، هناك قاعدة واحدة تخبر NLB بتحميل التوازن لأي حركة مرور واردة على أي منفذ، ولكن يمكنك تغيير هذا إذا كنت تريد. لا أرى الكثير من الأشخاص في الميدان يقومون بتحديد القواعد هنا لتوزيع منافذ محددة إلى وجهات محددة، ولكن إحدى الميزات الرائعة في هذه اللقطة هي القدرة على تعطيل نطاقات معينة من المنافذ. قد تكون هذه الوظيفة مفيدة جدًا إذا كنت تريد حظر حركة المرور غير الضرورية على مستوى NLB. على سبيل المثال، الشكل 12.7 يظهر تكوينًا يحظر المنافذ 81 وما فوق من المرور عبر آلية NLB:
أكمل هذا المعالج، وقد قمت الآن بإنشاء مجموعة NLB! ولكن في هذه المرحلة، حددنا فقط معلومات حول VIP، وحول خادم WEB1. لم نحدد أي شيء حول WEB2. نحن نشغل مجموعة NLB، ولكن حاليًا، تحتوي هذه المجموعة على عقدة واحدة فقط بداخلها، لذا فإن حركة المرور الموجهة إلى المجموعة تهبط كلها على WEB1. انقر بزر الماوس الأيمن على المجموعة الجديدة واختر Add Host To Cluster:
أدخل اسم خادم WEB2 الخاص بنا، انقر على Connect، وسر عبر المعالج لإضافة عقدة NLB الثانوية لـ WEB2 إلى المجموعة. بمجرد إضافة كلتا العقدتين إلى المجموعة، تكون مجموعة NLB الخاصة بنا، أو المجموعة، متصلة وجاهزة للاستخدام. (كما أخبرتك، يتم استخدام كلمة "مجموعة" في العديد من الأماكن، على الرغم من أن هذا لا يتحدث عن مجموعة تراجع على الإطلاق!)
إذا نظرت داخل خصائص بطاقة NIC الخاصة بخوادم الويب الخاصة بنا ونقرت على زر Advanced داخل خصائص TCP/IPv4، يمكنك رؤية أن عنوان IP الجديد للمجموعة 10.10.10.42 قد أضيف إلى بطاقات NIC. ستحتوي كل بطاقة NIC الآن على عنوان DIP المخصص لها، بالإضافة إلى عنوان VIP المشترك في المجموعة.
الآن، بدأت حركة المرور التي تتجه إلى عنوان IP 10.10.10.42 بالتوزيع بين العقدتين، ولكن حاليًا، المواقع التي تعمل على خوادم WEB1 وWEB2 مُعدة لتعمل فقط على العناوين 10.10.10.40 و10.10.10.41 المخصصة، لذا نحتاج للتأكد من تعديل ذلك بعد.
إعداد IIS وDNS
خطوة سريعة داخل IIS على كل من خوادم الويب لدينا يجب أن تجعل الموقع يستجيب على عنوان VIP المناسب. الآن بعد أن تم إعداد تكوين NLB وتأكدنا من إضافة عنوان VIP الجديد 10.10.10.42 إلى الـ NICs، يمكننا استخدام هذا العنوان كربط للموقع الإلكتروني. افتح وحدة إدارة IIS وقم بتوسيع مجلد Sites حتى تتمكن من رؤية خصائص موقعك الإلكتروني. انقر بزر الماوس الأيمن على اسم الموقع، واختر "Edit Bindings...":
بمجرد دخولك إلى "Site Bindings"، اختر الربط الذي تريد تعديله، وانقر على زر "Edit...". هذا الموقع الداخلي هو موقع HTTP بسيط، لذا سأختار الربط HTTP لهذا التغيير. الربط حالياً مضبوط على 10.10.10.40 على WEB1، و10.10.10.41 على WEB2. هذا يعني أن الموقع يستجيب فقط للحركة التي تأتي على هذه العناوين IP. كل ما علي فعله هو تغيير القائمة المنسدلة لعناوين IP إلى عنوان VIP الجديد، وهو 10.10.10.42. بعد إجراء هذا التغيير (على كلا الخادمين) والنقر على "OK"، سيبدأ الموقع في الاستجابة للحركة التي تأتي عبر عنوان IP 10.10.10.42:
الآن نأتي إلى القطعة الأخيرة من الأحجية: DNS
تذكر، نريد من المستخدمين أن يكون لديهم القدرة على إدخال http://intranet في متصفحات الويب الخاصة بهم لتصفح هذا الموقع الجديد لـ NLB، لذلك نحتاج إلى تكوين سجل DNS host A وفقاً لذلك. هذه العملية هي بالضبط مثل أي سجل DNS host آخر؛ ببساطة قم بإنشاء واحد وأشر إلى intranet.contoso.local إلى 10.10.10.42:
اختباره
تم تكوين NLB؟ تحقق.
تم تحديث روابط IIS؟ تحقق.
تم إنشاء سجل DNS؟ تحقق.
نحن جاهزون لاختبار هذا الشيء. إذا فتحت متصفح الإنترنت على جهاز كمبيوتر عميل وتصفحت إلى http://intranet، يمكنني رؤية الموقع:
ولكن كيف يمكننا تحديد أن موازنة التحميل تعمل حقًا؟ يمكنني إيقاف تشغيل خادم WEB1، محاكاة عطل، وسيعمل ذلك بشكل جيد. بدلاً من ذلك، إذا واصلت ببساطة تحديث الصفحة، أو تصفح من عميل آخر، أستمر في الوصول إلى صفحتي عبر نفس الاسم http://intranet، وفي النهاية، سيقرر آلية NLB أن يتم إرسال طلب جديد إلى WEB2 بدلاً من WEB1. عندما يحدث هذا، أُعرض على هذه الصفحة بدلاً من ذلك:
كما ترى، قمت بتعديل المحتوى بين WEB1 وWEB2 حتى أتمكن من التمييز بين العقد المختلفة، فقط لأغراض هذا الاختبار. إذا كان هذا موقع إنترانت حقيقي للإنتاج، أرغب في التأكد من أن محتوى كلا الموقعين هو نفسه تماماً، بحيث يكون المستخدمون غير مدركين تماماً لما يحدث من NLB. كل ما يحتاجون إلى معرفته هو أن الموقع سيكون متاحاً ويعمل في جميع الأوقات.
مسح ذاكرة ARP المؤقتة
سابقًا، تحدثنا قليلاً عن كيفية احتفاظ المحولات بذاكرة ARP المؤقتة، مما يقلل من الوقت الذي تستغرقه تلك المحولات عند تحديد المكان الذي يجب أن تتدفق فيه الحزم. عندما تعطي عنوان IP لبطاقة NIC، يرتبط عنوان MAC الخاص بتلك البطاقة بعنوان IP داخل جدول ARP لبعض معدات الشبكة.
المحولات، الموجهات، جدران الحماية – هذه الأدوات عادةً ما تحتوي على ما نطلق عليه جدول ARP، وتحتوي على مجموعة من البيانات في هذا الجدول تُعرف بذاكرة ARP المؤقتة.
عند تكوين NLB، خاصة البث الأحادي، يتم استبدال عنوان MAC لبطاقة NIC بعنوان MAC افتراضي جديد. أحيانًا، تكون المحولات ومعدات الشبكة سريعة جدًا في اكتشاف هذا التغيير، وتربط عنوان MAC الجديد بعنوان IP الجديد، وكل شيء يعمل بشكل جيد. ومع ذلك، أجد أنه عند تكوين NLB، يكون التالي صحيحًا عادةً: كلما كانت معدات الشبكة أكثر ذكاءً وأكثر تكلفة، كلما أصبحت أكثر غباءً عند تكوين NLB. ما أعنيه هو أن معدات الشبكة قد تستمر في الاحتفاظ بمعلومات عنوان MAC القديمة المخزنة في جدول ARP الخاص بها، ولا يتم تحديثها لتعكس عناوين MAC الافتراضية الجديدة.
كيف يبدو هذا في الحياة الواقعية؟ سيتوقف تدفق حركة المرور على الشبكة من أو إلى بطاقات NIC تلك. في بعض الأحيان، عندما تقوم بإعداد NLB وتقوم بتشغيله، تتوقف حركة المرور على الشبكة فجأة من أو إلى واجهات الشبكة. ماذا تحتاج أن تفعل لإصلاح هذا الوضع؟ أحيانًا يمكنك الانتظار، وفي غضون بضع دقائق أو ساعات أو حتى أيام، ستسقط المحولات معلومات ARP القديمة وتسمح بتسجيل عناوين MAC الجديدة في الجدول. ماذا يمكنك أن تفعل لتسريع هذه العملية؟ مسح ذاكرة ARP المؤقتة.
إجراءات القيام بذلك ستكون مختلفة اعتمادًا على نوع معدات الشبكة التي تعمل عليها – سواء كانت محولاً أو موجهًا، وما هي العلامة التجارية، وما هو الطراز، وما إلى ذلك. ولكن يجب أن تكون كل هذه المعدات قادرة على القيام بهذه الوظيفة، ويجب أن يُطلق عليها شيئًا على غرار مسح ذاكرة ARP المؤقتة. عند تشغيل هذه الوظيفة على معداتك، فإنها تنظف جدول ARP، وتتخلص من المعلومات القديمة التي تسبب لك مشاكل وتسمح لعناوين MAC الجديدة بالتسجيل بشكل صحيح في الجدول الجديد.
أردت فقط الإشارة إلى هذا في حال قمت بتكوين NLB فقط لترى حركة المرور تتوقف على خادمك. على الأرجح، أنت تتعامل مع ذاكرة ARP المؤقتة العالقة على قطعة واحدة أو أكثر من معدات الشبكة التي تحاول نقل الحركة من وإلى خادمك.
التجميع الفاشل (Failover Clustering)
لقد أقررنا أن NLB هو حل رائع للتطبيقات التي لا تعتمد على الحالة (stateless)، والمثال الرئيسي هو المواقع الإلكترونية التي تريد جعلها متاحة بشكل كبير. ماذا عن الأدوار أو الوظائف الأخرى للخوادم التي تريد جعلها زائدة؟ حسنًا، العكس من stateless هو stateful، فكيف يمكنك توفير التوافر العالي للتقنيات التي تعتمد على الحالة؟
يوفر التجميع الفاشل هذا المستوى من القدرة ويمكن استخدامه في الحالات التي تصل فيها العقد داخل التجمع إلى بيانات مشتركة. هذه نقطة رئيسية في كيفية تصميم التجميع الفاشل. يجب أن تكون وحدة التخزين المستخدمة من قبل عقد التجمع مشتركة ومتاحة لكل عقدة تحتاجها. هناك العديد من الأدوار والخدمات المختلفة التي يمكنها الاستفادة من التجميع الفاشل، ولكن هناك أربع تقنيات محددة يبدو أنها تشكل غالبية التجمعات التي تعمل في مراكز البيانات اليوم: Hyper-V، خدمات الملفات، Exchange، وSQL. إذا كنت تعمل مع أي من هذه التقنيات – ومن المحتمل أنك تعمل مع جميعها – يجب عليك النظر في قدرات التوافر العالي التي يمكن أن يوفرها التجميع الفاشل لبنيتك التحتية.
بينما يتم توفير التجميع الفاشل بواسطة Windows Server وهو من تصميم Microsoft ولديه القدرة على العمل بشكل جيد جدًا مع العديد من الأدوار والخدمات من Microsoft، من المهم ملاحظة أنه يمكنك إنشاء التجميع الفاشل للتطبيقات غير التابعة لـ Microsoft أيضًا.
يمكن للتطبيقات التابعة لجهات خارجية التي تعمل على Windows Server في بيئتك، أو حتى التطبيقات المنزلية التي تم بناؤها داخليًا، أن تستفيد أيضًا من التجميع الفاشل. طالما أن هذا التطبيق يستخدم وحدة تخزين مشتركة ويمكنك تحديد المهام التي يحتاج إلى تنفيذها ضد تلك التطبيقات لأدوات إدارة التجمع – كيفية بدء الخدمة، كيفية إيقاف الخدمة، كيفية مراقبة صحة الخدمة، وما إلى ذلك – يمكنك توصيل هذه الخدمات والتطبيقات المخصصة بالتجميع الفاشل وتوفير قدر كبير من الزائدة لأي نوع من التطبيقات تقريبًا.
تجميع مضيفات Hyper-V
أحد الأمثلة الأكثر قوة على التجميع الفاشل يتم عرضه عند دمج التجميع مع Hyper-V. من الممكن بناء خادمين أو أكثر من Hyper-V، وتجمعهم معًا، وتمنحهم القدرة على استضافة جميع الآلات الافتراضية المخزنة في تلك البيئة الافتراضية. من خلال منح جميع خوادم Hyper-V المضيفة إمكانية الوصول إلى نفس وحدة التخزين المشتركة حيث يتم تخزين الأقراص الصلبة الافتراضية، وتكوين التجميع الفاشل بين العقد، يمكنك إنشاء حل افتراضي قوي جدًا وزائد لشركتك. عندما يتعطل خادم Hyper-V، فإن الآلات الافتراضية التي كانت تعمل على هذا المضيف ستنتقل إلى خادم Hyper-V آخر وتدور هناك بدلاً منه.
بعد انقطاع خدمة بسيط بينما تدور الآلات الافتراضية، تعود كل شيء عبر الإنترنت تلقائيًا، دون أي تدخل إداري. والأفضل من ذلك، ماذا عن عندما تحتاج إلى تصحيح أو إزالة خادم Hyper-V من الخدمة للصيانة؟ يمكنك بسهولة إجبار الآلات الافتراضية على العمل على خادم عضو مختلف في التجمع؛ يتم نقلها عبر الإنترنت إلى ذلك الخادم بحيث لا يكون هناك أي وقت تعطل، ثم يمكنك إزالة العقدة للصيانة والانتهاء من العمل عليها قبل إعادة تقديمها إلى التجمع. نحن نستخدم الآلات الافتراضية والخوادم لجميع أنواع الأعمال، لذا ألن يكون رائعًا إذا كنت تستطيع التخلص من أي نقطة فشل واحدة في تلك البيئة الافتراضية؟ هذا هو بالضبط ما يمكن أن يوفره التجميع الفاشل.
موازنة حمل الآلات الافتراضية
في الواقع، ليس فقط أن تجمع Hyper-V لديه القدرة على التعافي الذاتي بسرعة في حالة تعطل عقدة خادم Hyper-V، ولكن لدينا الآن بعض المنطق الذكي لموازنة الحمل يعمل مع هذه الخدمات المجمعة. إذا كان تجمع Hyper-V الخاص بك يصبح محملاً بشكل زائد بالآلات الافتراضية، فإنه من المنطقي أن تضيف عقدة أخرى إلى ذلك التجمع، مما يمنح التجمع المزيد من القدرة وقوة الحوسبة. ولكن بمجرد إضافة العقدة، كم من العمل يتطلبه تحريك بعض الآلات الافتراضية إلى هذه العقدة الجديدة في التجمع؟ لا شيء! طالما أنك قمت بتمكين موازنة حمل الآلات الافتراضية، فسيتم تقييم أوزان التجمع تلقائيًا، وسيتم نقل أحمال العمل للآلات الافتراضية، دون وقت تعطل، في الوقت الفعلي، لتحسين توزيع العمل بين جميع العقد في التجمع، بما في ذلك الخادم المضيف الجديد. يمكن تشغيل موازنة حمل الآلات الافتراضية وتقييمها عند الطلب، كلما رأيت ذلك مناسبًا، أو يمكن تكوينها لتعمل تلقائيًا، وتنظر في البيئة كل 30 دقيقة، وتتخذ القرار تلقائيًا بشأن ما إذا كان يجب نقل أي أحمال عمل.
تجميع خوادم الملفات
كان تجميع خوادم الملفات متاحًا لفترة طويلة؛ كان هذا أحد الأغراض الأصلية وراء إصدار التجميع. في الأصل، كان تجميع خوادم الملفات مفيدًا فقط للاستخدام التقليدي للملفات والمستندات؛ بعبارة أخرى، عندما يحتاج المستخدمون إلى الوصول إلى الملفات والمجلدات يوميًا، وتريد أن تكون تلك الملفات متاحة بشكل كبير. حتى يومنا هذا، يعمل تجميع خوادم الملفات العامة في سيناريو نشط-سلبي. عندما يتم تجميع خوادم ملفات متعددة للوصول العام إلى الملفات، تكون واحدة فقط من تلك العقد نشطة ومقدمة للمستخدمين في وقت واحد. فقط في حالة تعطل تلك العقدة يتم نقل الدور إلى عضو آخر في التجمع.
خادم الملفات الممتد
بينما يعتبر تجميع خوادم الملفات العامة رائعًا للوصول العشوائي إلى الملفات والمجلدات، إلا أنه ليس شاملاً بما يكفي للتعامل مع الملفات التي تظل مفتوحة باستمرار أو تتغير. مثال رئيسي على هذه الملفات هو ملفات الأقراص الصلبة الافتراضية المستخدمة بواسطة آلات Hyper-V الافتراضية.
هناك حاجة لأن تكون ملفات الأقراص الصلبة الافتراضية هذه زائدة؛ فقدان هذه الملفات سيكون مدمراً لأعمالنا. لحسن الحظ، استضافة أعباء العمل بالبيانات التطبيقية مثل هذه هو بالضبط ما يفعله خادم الملفات الممتد (SOFS). إذا كنت تخطط لاستضافة الآلات الافتراضية باستخدام Hyper-V، فستريد بالتأكيد التحقق من قدرات التجميع الفاشل المتاحة للاستخدام مع خدمات Hyper-V. بالإضافة إلى ذلك، إذا كنت تنوي استخدام مضيفات Hyper-V المجمعة، فيجب عليك التحقق من
SOFS. تعمل SOFS في وضع نشط-نشط مع كل عضو في التجمع، ويستطيع كل مضيف من مضيفي Hyper-V الوصول إلى جميع الأقراص الصلبة الافتراضية الموجودة داخل هذه البيئة. تقدم SOFS التوافر العالي والتوازن المحسن للأحمال والدقة المستمرة لأعباء العمل التي تعتمد على البيانات والمخزنة في الملفات التي تحتاج إلى أن تكون زائدة.
الأدوار المجمعة الأخرى
بينما تعتبر الآلات الافتراضية وخوادم الملفات هي التقنيات الأكثر شيوعًا للاستفادة من التجميع الفاشل، إلا أنها ليست الوحيدة. ماذا عن نظام البريد الإلكتروني الخاص بك؟ Exchange هو دور آخر يتم تجميعه بشكل متكرر جدًا. بينما تم تصميم Exchange مع قدرات الزائدة الخاصة به، يمكن أن يستفيد بشكل كبير من العمل على بنية تحتية تقوم بتشغيل التجميع الفاشل. يتم تجميع قواعد البيانات داخل Exchange، وهذا يمكن أن يوسع ذلك التجميع عبر عدة أجهزة Exchange، كل منها يمكن أن يعمل بشكل مستقل أو مع بعضها البعض.
ال SQL Server هو دور آخر يستفيد بشكل كبير من التجميع الفاشل. يمكن استضافة قواعد البيانات التي تحتوي على المعلومات الأساسية داخل عملك في بيئة SQL Server مجمعة، مما يضمن عدم وجود نقطة فشل واحدة بالنسبة لتلك البيانات، وأنه يمكن الوصول إلى بيانات الشركة الخاصة بك باستمرار من قبل المستخدمين والتطبيقات.
النهاية
نكون هنا انتهينا من الجزء 1 من الفصل 12 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
