إن ترحيل أنظمة تكنولوجيا المعلومات ليس بالمهمة السهلة. لكن الصعوبة الخاصة هي الحالة التي لا تحتاج فيها فقط إلى التبديل من الحديد القديم إلى الجديد ، ولكن للانتقال إلى نظام تشغيل جديد على المعدات الموجودة ، وبدون ترحيل البيانات المنتجة. استمرت إحدى هذه الخطوات حوالي عام ، استغرق معظمها التحضير.
لدى العميل موقعين في مدن مختلفة ، ولكل منهما نظامان لتخزين البيانات متصلان. يتم إرسال المعلومات من نظام تخزين واحد باستخدام أدوات النسخ المتماثل المضمنة إلى الثانية. يتم تنفيذ الإدارة باستخدام نظام النسخ الاحتياطي الخارجي. في إحدى المدن ، تم تثبيت نظامين NetApp 3250 ، في الآخر - NetApp 6220 الرئيسي و NetApp 3250 الاحتياطي. يخطط العميل لتوسيع هذا المجمع في المستقبل وإضافة أقراص وترقية وحدات التحكم.
التين. 1 مخطط تفاعل أنظمة التخزين و IBSوالمشكلة الرئيسية مرتبطة بهذا - نهاية الدعم. بالنسبة لنظام تشغيل Data ONTAP 8.2 ذو 7 أوضاع والمثبت على نظام التخزين ، لم تكن هناك تحديثات رئيسية لبضع سنوات ، وسيتوقف إصدار تصحيحات الأخطاء الفادحة في عام 2021. لا تتوافق محركات الأقراص وأجهزة التحكم الأحدث مع نظام التشغيل القديم.
الحل هو الانتقال إلى نظام مجموعة ONTAP 9.1 باعتباره آخر نظام مدعوم لوحدات التحكم في التخزين هذه. مزاياها الرئيسية هي:
- التحجيم الأفقي من خلال الدمج في مجموعة واحدة تتسامح مع الأخطاء ، والتي ستسمح لك بإنشاء نظام واحد يعتمد على التخزين الإنتاجي و SRK.
- موازنة التحميل بين وحدات التحكم والأقراص وكذلك نقل البيانات داخل نظام التخزين دون مقاطعة الخدمة وإيقاف الوصول إلى التطبيقات.
- صيانة الأجهزة والبرمجيات لأنظمة تخزين البيانات دون انقطاع عملهم وانقطاع الخدمة.
- القدرة على إنشاء تكوينات عنقودية غير متجانسة ، بما في ذلك وحدات التحكم والأقراص من أنواع مختلفة ، بما في ذلك أنظمة التخزين التابعة لجهات خارجية ، وتخضع لاستخدام التراخيص لمحاكاة سعة القرص الافتراضية الخاصة بهم.
- القدرة على استخدام SSD كطبقة تخزين مؤقت للمجموعات.
- التشغيل الأمثل لآليات ضغط البيانات (الضغط وإلغاء البيانات المكررة).
هناك 3 خيارات للترحيل من وضع 7 إلى وضع الكتلة:
- الترحيل باستخدام النسخ المتماثل للبيانات باستخدام أداة الانتقال Netapp 7-Mode (7MTT) والانتقال المستند إلى النسخ (CBT). لهذا ، مطلوب نظام تخزين ثان مع مساحة قرص أصغر والنسخ المتماثل على مراحل على SnapMirror. لكل خدمة ، يتم تنسيق التبديل وتنفيذه في وقت معين.
في أحد عملائنا ، قمنا بالفعل بهذا الإجراء على كتلة المترو. نظرًا للعدد الكبير من الأحجام ، LUNs (> 400) والتنسيق الطويل للتفاصيل ، وأوقات التعطل ، وما إلى ذلك. استغرق الهجرة حوالي 3 أشهر ، باستثناء التدريب. - قم بالترحيل بدون نقل البيانات باستخدام أداة النقل لـ Netapp 7-Mode (7MTT) والانتقال الخالي من النسخ (CFT). للقيام بذلك ، تحتاج إلى نظام تخزين ثانٍ مع الحد الأدنى من الأقراص ، والتي بعد الإعداد الأولي ستبدل النظام الفرعي للقرص المنتج. بالنسبة لجميع الخدمات ، يتم الاتفاق على فترة توقف كبيرة واحدة.
- الترحيل مع نسخ البيانات باستخدام أدوات المضيف. هذا هو مسار الترحيل التقليدي بين أنظمة التخزين لأي مصنع.
نظرًا لأن أنظمة التخزين الحالية كانت لا تزال تحت دعم البائعين ، وكان أداء وحدات التحكم في المستقبل القريب كافيًا ، لم يتم تخصيص ميزانية لشراء وحدات تحكم جديدة. في هذا الصدد ، تقرر ترحيل وحدات التحكم إلى وضع الكتلة باستخدام 7MTT CFT. كان أحد المتطلبات الرئيسية هو عدم وجود انقطاعات ملحوظة في تشغيل أنظمة التخزين: يجب أن تعمل معظم الأنظمة بسلاسة في أيام الأسبوع. لذلك ، تمت جدولة العمل الرئيسي بشأن الهجرة على نظام تخزين منتج في عطلة نهاية الأسبوع.
بدأت مرحلة التحضير بجمع المعلومات من نظام التخزين وإجراء الفحوصات الأولية. ينشئ برنامج NetApp 7MTT المتخصص قائمة من التنبيهات التي قد تتداخل مع الترحيل أو تفشل في إكماله. على سبيل المثال ، بالنسبة لأحد الأنظمة ، تألفت هذه القائمة من أكثر من 200 عنصر. كان من الضروري تحديث جميع الأنظمة إلى أحدث الإصدارات المدعومة من نظام التشغيل وتحديث البرامج الثابتة لوحدات التحكم وأرفف الأقراص والأقراص نفسها. كما أن نظام التشغيل الجديد له منطق تشغيل مختلف ، الأمر الذي يتطلب عناوين IP إضافية واتصالات بين أنظمة التخزين.
تم اكتشاف عامل التوقف بسرعة كبيرة - استخدم العميل التكنولوجيا التي لم تستند إلى النسخ المتماثل للحجم بالكامل ، ولكن على النسخ المتماثل qtree (القسم الفرعي الذي تنطبق عليه قيود الوصول والحجم وما إلى ذلك) ومن المستحيل ترحيل علاقات SnapVault إلى نظام التشغيل الجديد . نتيجة لذلك ، قبل البدء في العمل ، سيكون من الضروري إزالة جميع نسخ النسخ المتماثل بالكامل. لضمان عدم ترك العميل بعد النقل بدون نسخ احتياطية ، تم بدء النسخ الاحتياطي المستند إلى النسخ المتماثل لوحدة التخزين بالكامل قبل الترحيل. باستخدام SnapMirror ، تم إنشاء نسخ احتياطية جديدة بجانب القديمة ، وتم تجميع سجل التغييرات في غضون أربعة أسابيع. وإذا كان هناك مساحة كافية لذلك في أحد المواقع ، فقد كانت المساحة الثانية محدودة ، وكان من الضروري عمل نسخ تدريجية من أحد المجلدات. بعد أربعة أسابيع ، تمت إزالة العلاقات القديمة وإنشاء علاقات جديدة. عملية مطولة إلى حد ما ، استغرقت حوالي 1.5 شهرًا في حالة موقع واحد ، وأكثر من 3 في الثانية. بالإضافة إلى ذلك ، أود أن أشير إلى أن إجراء إيقاف علاقة Snapvault مصحوب بإزالة qtree المستهدفة وسرعة تنفيذها تعتمد بشدة على عدد الملفات وبدرجة أقل على حجمها. على سبيل المثال ، تم حذف qtree الذي يحتوي على 4 ملايين ملف وحجم 500 جيجابايت في غضون 24 ساعة.
في هذه العملية ، نشأت صعوبات مختلفة. أدت بيروقراطية عمليات إجراء التغييرات على أنظمة العملاء إلى زيادة شروط تنسيق العمل. لحسن الحظ ، تمكنا من الاتفاق على حل المشكلات الفنية مباشرة ، ومناقشة القضايا "الإيديولوجية" المهمة فقط على مستوى أعلى ، مثل الاتفاق على خطة عمل واختيار تواريخ محددة للهجرة.
كانت الصعوبات بسبب استخدام التخزين المؤقت. بتوجيه من 7MTT ، قمنا بتهيئة نظامي التخزين وفقًا للمتطلبات والفحوصات المسبقة. ثم أوقفوا التخزين القديم وربطوا أرفف القرص بالجهاز الجديد. فحص كل شيء مرة أخرى. من وجهة نظر برنامج NetApp ، تكتمل عملية الترحيل ويتفرق الجميع
خلف الشمبانيا . ولكن الخطوة التالية كانت إعادة كل شيء إلى وحدات تحكم العميل القديمة. والحقيقة هي أن هذا الانتقال - من وحدات التحكم الجديدة إلى القديمة - غير مدعوم رسميًا. بعد التبديل مرة أخرى ، بدأ نظام التشغيل يتدفق من الأخطاء ويشكو من مشاكل في المجموعة. بعد البحث ، تمكنت من معرفة أن المشكلة ترجع إلى حقيقة أن المجموعة تحولت فجأة إلى وضع التبديل ولم ترغب في العودة إلى وضع التبديل. استغرق الأمر وقتًا طويلاً لإصلاح الخطأ. تم حل مشاكل إطلاق الكتلة من خلال عدم توصيل الكابلات المؤدية إلى الشبكة القتالية عند بدء التشغيل ، وتم رفع الشبكة داخل الكتلة على كابل واحد ، ثم تمت إضافة الكبل الثاني. بالمناسبة ، يجب أن نتذكر أنه على وحدات التحكم القديمة والإصدارات القديمة من نظام التشغيل ، لا يمكن رفع الشبكة داخل الكتلة إلا على منافذ معينة من مجموعة محدودة من المحولات ، على سبيل المثال ، على FAS3250 يكون e1a و e2a (كان على العميل شراء بطاقات إيثرنت 10 جيجابايت).
لقد وضعوا وقتًا إضافيًا للعمل على الموقع الثاني ، على أمل تجنب بعض المشاكل على الأقل ، لكن هذا لم يساعد - تصرف نظام التشغيل بشكل غير متوقع. تم تغيير الرسم البياني مرتين. في الحالة الأولى ، عندما كنا نعمل مع FAS3250 ، لم يكن من الممكن ترحيل أنظمة قتالية تعمل على مدار الساعة طوال أيام الأسبوع بسبب خطأ في الإعدادات التي تم تغييرها مؤخرًا في البنية التحتية لشبكة العميل (على الرغم من أنه عند اختبار الترحيل قبل أسبوع من بدء العمل ، طار كل شيء). نسخ vMotion الأجهزة الافتراضية بسرعة أقل من 1 ميجابت في الثانية إلى نظام تخزين بعيد.
أثناء الترحيل ، قام العميل بتغيير البنية جزئيًا. تم إصدار وحدات التخزين التي تم توزيعها على بنية VMware vSphere الأساسية الخاصة بها مسبقًا عبر NFS Ethernet. قام العميل بإعادة تصميمها ، وانتقل إلى القناة الليفية. أثناء عملية الترحيل ، اتضح أن LUN غيرت معرفها تمامًا ، وبالتالي ، رأى VMware LUNs جديدة تم توجيهها إليه بالبيانات القديمة ، ورفض توصيلها بشكل دائم. ونتيجة لذلك ، وبفضل مساعدة متخصصي VMware ، كان من الممكن توصيل وحدات LUN هذه من خلال وحدة التحكم بشكل مستمر ، مما يشير إلى أن هذه لقطة من مخازن البيانات القديمة. ثم اضطررت إلى إعادة تشغيل مضيفي VMware. ونتيجة لذلك ، تمكنوا من رؤية الأجهزة الافتراضية ورفع البنية التحتية الافتراضية. وإذا استمر العميل في استخدام NFS ، فلن تكون هذه المشكلة قد نشأت - حيث ظل عنوان IP واسم DNS كما كان من قبل.
خطة العمل مباشرة في أيام الهجرة:
الجمعة: العمل مع أنظمة التخزين و IBS
- أوقفوا جميع العلاقات بين SnapVault و SnapMirror ، وبدلوا التخزين المؤقت وتحققوا من أن الأنظمة جاهزة للترحيل. بدأنا إجراءات ترحيل التخزين إلى 7MTT باستخدام طريقة النسخ الحر للانتقال. إعادة توصيل أفواج القرص القتالي إلى وحدة التحكم المؤقتة.
- تم ترحيلها إلى 7MTT ، وتم ترحيل المجلد الجذر لوحدات التحكم البديلة إلى أرفف القرص لنظام التخزين في SRK. لقد قمنا بتركيب محولات إيثرنت جديدة ، وأطلقنا نظام تخزين SRK ، ومحو التكوين ، وقمنا بتنزيل صورة نظام التشغيل عبر الشبكة من خادم HTTP. لقد قمنا بتثبيت إصدارات جديدة من البرامج الثابتة ونظام التشغيل (في هذه المرحلة كانت هناك مشكلات غير مبررة في تنزيل الصورة عبر الشبكة. وفي النهاية ، تم تنزيلها مباشرة من الكمبيوتر المحمول).
- لقد استبدلنا وحدات التحكم في المجموعة بأخرى قديمة وقمنا بتوصيل أرفف قرص المعركة بنظام التخزين باستخدام الترقية عن طريق نقل إجراء التخزين. استعدنا المجموعة ، وأعدنا تهيئة واجهات الشبكة (كان عليّ حل المشكلات المرتبطة بالتشغيل غير الصحيح للكتلة) وتثبيت مفاتيح الترخيص.
السبت: العمل مع التخزين الرئيسي
- قمنا بتوصيل أرفف الأقراص المؤقتة بالتخزين المؤقت وإعداده مرة أخرى.
- تم ترحيل الأجهزة الافتراضية المهمة إلى التخزين إلى مركز بيانات بعيد باستخدام VMware vMotion.
- تم ترحيل أنظمة التخزين الرئيسية إلى 7MTT باستخدام طريقة CFT. قاموا بإيقاف تشغيل التخزين القتالي الرئيسي ، وربطوا أرفف الأقراص الخاصة به بوحدة التحكم وتحويل بيانات تعريف نظام التشغيل إلى 7MTT. تم ترحيل المجلد الجذر لوحدات التحكم في المبادلة إلى أرفف القرص لنظام تخزين SRK.
- لقد قمنا بتثبيت محولات إيثرنت جديدة وأطلقنا تخزين المعركة في تكوين بدون قرص ، ومحو الإعدادات ، ثم تنزيلها عبر الشبكة من خادم HTTP. تثبيت إصدارات جديدة للبرامج الثابتة ونظام التشغيل. لقد استبدلنا وحدات التحكم في المجموعة ، وربطنا أرفف الأقراص القتالية بنظام التخزين باستخدام الترقية عن طريق نقل إجراء التخزين.
- استعادة الكتلة ، واجهات الشبكة المعاد تكوينها (الترقيع مع الكتلة تعمل بشكل غير صحيح بسبب واجهات شبكة قتالية متصلة). مفاتيح الترخيص المثبتة.
- لقد استعدنا اتصالات التخزين إلى خوادم VMware ، وقمنا بتغيير المناطق في شبكة SAN ، وقمنا بتكوين تعيين LUNs ، ونقل وحدات التخزين إلى SVM منفصل للعمل مع وصول FC. توصيل LUN بـ ESXi. نظرًا لحقيقة أن معرف LUN قد تغير ، لم تظهر مخازن البيانات في الوضع التلقائي ، كان علي إعادة تشغيل خوادم ESXi باستمرار وتوصيل LUNs بالأوامر عبر esxcli.
- أعيدت تهيئة واجهات المعارك ، وأعدت تسمية خوادم CIFS واستعادت الوصول إلى كرات CIFS وتصدير NFS.
الأحد: حل المشكلات وإعداد برنامج IBS
- تم ترحيل الأجهزة الافتراضية مرة أخرى من نظام التخزين إلى نظام التخزين القتالي.
- لقد حللنا مشكلة الوصول إلى المجلد في وضع التسجيل من مضيف Linux. لقد نشرنا أحدث إصدار من برنامج مراقبة Netapp onCommand Unified Manager 7.3 وقمنا بتوصيل نظامي التخزين به.
- قمنا بتحليل بيانات الحمل الحالي على الوحدات باستخدام برنامج Unified Manager ، باستخدام SSD قمنا بتوصيل طبقة التخزين المؤقت بوحدات القرص الموجودة (Flash / Storage Pool).
- قاموا بإيقاف تشغيل نظام التخزين البديل ، وأنشأوا روابط عنقودية (نظير الكتلة ، نظير SVM) بحيث يمكن استخدام النسخ المتماثل. أنشأنا علاقات SnapMirror جديدة بين التخزين الرئيسي وتخزين SRK استنادًا إلى وحدات التخزين الحالية (التي تم استخدامها في علاقات وضع SnapMirror 7) مع إعادة مزامنة البيانات المتغيرة ، ثم قمنا بتحويل علاقات SnapMirror إلى علاقات SnapVault (SnapMirror XDP).
- لقد قمنا بتوصيل كلا نظامي التخزين ببرنامج Commvault SRC في وضع النسخ المتماثل لـ OpenApp باستخدام الدعم الفني Commvault ، إلا أنه لم يعمل بشكل مختلف ، على الرغم من أننا قمنا بكل شيء وفقًا للتعليمات. إرسال سجلات الدعم التلقائي من أنظمة التخزين والتخزين القتالية من SRK.
الاثنين: طحن
- التحقق من تشغيل أنظمة التخزين والتخزين الإنتاجية الرئيسية لنظام التخزين. حل المشكلات والأعطال المحتملة.
- فصل وتفكيك المعدات المؤقتة.
استغرقت الهجرة نفسها يومين فقط. كانت الخطوة ناجحة ، وجميع بيانات العملاء آمنة وسليمة. كما تم الحفاظ على نظام إدارة النسخ الاحتياطي والتكامل مع برنامج SRK الحالي. إذا سبق لك استخدام حزمة Commvault مع OnCommand Unified Manager ، فبعد التبديل إلى وضع الكتلة ، تقرر التخلي عنها لصالح Netapp Open Replication لتوصيل Commvault مباشرة بوحدات تحكم التخزين.
التوصيات الرئيسية التي يمكنني تقديمها استنادًا إلى نتائج هذا الترحيل: قم بالتبديل من وضع 7 إلى وضع الكتلة إلى جانب استبدال وحدات التحكم. إذا كنت لا تزال تخطط للانتقال إلى وحدات التحكم الثانية ، كما هو الحال في الحالة الموضحة أعلاه ، فأنت بحاجة إلى التخطيط لوقت كافٍ لحل المشكلات المختلفة التي ستنشأ بالضرورة عند الرجوع إلى وحدات التحكم القديمة. يعد استخدام الترحيل بدون نقل البيانات باستخدام 7MTT CFT إجراءً آمنًا تمامًا ، إذا وثق به المحترفون.
أدلة مفيدة مستخدمة أثناء هذا الترحيل:
ديمتري كوستريوكوف ، مهندس تصميم رائد لأنظمة التخزين
مركز تصميم مجمعات الحاسب الآلي "Jet Infosystems"