إذا نظرنا إلى الوراء ، يمكنني القول أن جميع إجراءات التنسيب منذ ذلك الحين هي تحركات قسرية. والآن فقط ، في السنة الخامسة عشرة ، يمكننا تكوين البنية التحتية بالطريقة التي نحتاجها.
نحن الآن نقف في 4 مراكز بيانات مختلفة ماديًا ، متصلة بحلقة من البصريات الداكنة ، ونضع 5 تجمعات موارد مستقلة هناك. وحدث أنه إذا ضرب نيزك أحد الصلبان ، فسوف تسقط 3 من هذه التجمعات على الفور ، ولن يسحب الاثنان المتبقيان الحمل. لذلك بدأنا إعادة توازن كاملة لترتيب الأمور.
مركز البيانات الأول
في البداية لم يكن هناك مركز بيانات. كان هناك نظامي قديم في عنبر MSU. ثم ، على الفور تقريبًا - استضافة افتراضية من Masterhost (لا يزالون على قيد الحياة ، شياطين). تضاعفت حركة المرور إلى الموقع مع جدول القطار كل 4 أسابيع ، لذلك سرعان ما تحولنا إلى KVM-VPS ، حدث ذلك في حوالي عام 2005. في مرحلة ما ، واجهنا قيودًا على حركة المرور ، لأنه كان من الضروري في ذلك الوقت الحفاظ على التوازن بين الوارد والصادر. كان لدينا تركيبان ، وقمنا بتحويل ملفين مهمين من واحد إلى آخر كل ليلة من أجل الحفاظ على النسب المطلوبة.
في مارس 2009 كان هناك فقط VPS... هذا شيء جيد ، قررنا التحول إلى التجميع. اشترينا اثنين من خوادم الحديد المادية (أحدهما هو من الجدار ، الذي نخزن جسمه كذاكرة). لقد وضعوا Fiord في مركز البيانات (وما زالوا أحياء ، شياطين صغار). لماذا ا؟ وأوصى صديق ، لأنه لم يكن بعيدًا عن المكتب في ذلك الوقت ، واضطررت إلى النهوض بسرعة. بالإضافة إلى أنها كانت رخيصة نسبيا.
كانت مشاركة الحمل بين الخوادم بسيطة: كان لكل منها خلفية ، MySQL مع النسخ المتماثل الرئيسي ، كانت الواجهة في نفس مكان النسخة المتماثلة. حسنًا ، أي تقريبا بدون تقسيم حسب نوع الحمل. وسرعان ما بدأوا يفتقدون أيضًا ، واشتروا ثالثًا.
حوالي 1 أكتوبر 2009 ، أدركنا أن هناك بالفعل المزيد من الخوادم ، لكننا سنستقر للعام الجديد... أظهرت توقعات حركة المرور أن السعة المحتملة سيتم قطعها بهامش. وواجهنا أداء قاعدة البيانات. كان هناك شهر ونصف للاستعداد قبل نمو حركة المرور. كان هذا هو وقت التحسين الأول. اشترينا خادمين فقط لقاعدة البيانات. ركزوا على الأقراص السريعة بسرعة دوران تبلغ 15krpm (لا أتذكر السبب الدقيق لعدم استخدام محركات الأقراص ذات الحالة الثابتة ، ولكن على الأرجح كان لديهم حد منخفض على عدد عمليات الكتابة ، وفي نفس الوقت التكلفة مثل الطائرة). قسّمنا قواعد البيانات الأمامية والخلفية وقلبنا إعدادات nginx و MySQL ، ونفذنا عملية استئصال لتحسين استعلامات SQL. لقد نجا.
نحن الآن نقف في زوج من مراكز البيانات من المستوى الثالث وفي واجهة المستخدم من المستوى الثاني (مع تراجع في T3 ، ولكن بدون شهادات). لكن Fiord لم يكن أبداً حتى T-II. كان لديهم مشاكل البقاء على قيد الحياة ، وكانت هناك حالات من الفئة "جميع أسلاك الكهرباء في جامع واحد ، وكان هناك حريق ، وقاد المولد لمدة ثلاث ساعات". بشكل عام ، قررنا التحرك.
اختر مركز بيانات آخر ، Caravan... التحدي: كيفية نقل الخوادم دون توقف؟ قررنا العيش في مركزي بيانات لفترة من الوقت. لحسن الحظ ، لم تكن حركة المرور داخل النظام في ذلك الوقت كما هي الآن ، فقد كان من الممكن قيادة حركة المرور عبر VPN بين المواقع لبعض الوقت (خاصة خارج الموسم). جعل موازنة حركة المرور. قمنا بزيادة حصة الكارافان تدريجيًا ، بعد فترة انتقلنا تمامًا إلى هناك. والآن بقي لدينا مركز بيانات واحد. وتحتاج إلى اثنين ، لقد فهمنا هذا بالفعل ، وذلك بفضل الفشل في المضيق البحري. بالنظر إلى تلك الأوقات ، يمكنني القول أن المستوى الثالث ليس دواءً لكل داء ، وستكون قابلية البقاء 99.95 ، ولكن إمكانية الوصول أخرى. لذا فإن مركز بيانات واحد لا يكفي بالتأكيد لتوفر 99.95 وأعلى. تم
اختيار Stordata في المرتبة الثانية، وكان هناك بالفعل إمكانية وجود رابط بصري مع موقع القافلة. تمكنا من تمديد الوريد الأول. بمجرد أن بدأوا في تحميل مركز البيانات الجديد ، أعلنت Caravan أنها حصلت على مؤخرتها. اضطروا لمغادرة الموقع بسبب هدم المبنى. سابقا. مفاجأة! هناك موقع جديد ، يقترحون إطفاء كل شيء ، رافعات لرفع الرفوف بالمعدات (ثم كان لدينا بالفعل 2.5 رفوف من الحديد) ، ترجمة ، تشغيلها ، وستعمل ... 4 ساعات لكل شيء ... حكايات ... أنا صامت حتى لدينا ساعة من التوقف لم يكن مناسبًا ، لكن القصة كانت ستستمر لمدة يوم على الأقل. وكل هذا تم تقديمه بروح "كل شيء رحل ، تم إزالة الجص ، العميل غادر!". في 29 سبتمبر ، المكالمة الأولى ، وفي 10 أكتوبر ، أرادوا أخذ كل شيء وأخذه. في 3-5 أيام كان علينا أن نطور خطة نقل ، وفي 3 مراحل ،إيقاف تشغيل 1/3 من المعدات في وقت واحد مع الحفاظ الكامل على الخدمة ووقت التشغيل لنقل السيارات إلى Stordata. ونتيجة لذلك ، كان التوقف عن العمل 15 دقيقة في خدمة ليست الأكثر أهمية.
لذا مرة أخرى تركنا مع مركز بيانات واحد.
في هذه اللحظة ، سئمنا من السير على الأقدام مع الخوادم تحت ذراعنا ولعب اللوادر. بالإضافة إلى تعبت من القيام بالمكواة نفسها في مركز البيانات. بدأوا يتطلعون نحو الغيوم العامة.
من 2 إلى 5 مراكز بيانات (تقريبًا)
بدأت تبحث عن خيارات مع الغيوم. ذهبنا إلى كروك ، جربناه ، اختبرناه ، وافقنا على الشروط. وصلنا إلى السحابة ، الموجودة في مركز بيانات الضاغط. لقد صنعوا حلقة من البصريات الداكنة بين Stordata و Compressor والمكتب. في كل مكان وصلته الخاصة وذراعا من البصريات. قطع أي من الأشعة لا يدمر الشبكة. لا يؤدي فقد الوصلة الصاعدة إلى تدمير الشبكة. حصلنا على حالة LIR ، لدينا شبكتنا الفرعية الخاصة ، وإعلانات BGP ، نحتفظ بالشبكة والجمال. لن أصف كيف دخلوا إلى السحابة من وجهة نظر الشبكة ، ولكن كانت هناك فروق دقيقة.
إذن لدينا مركزان للبيانات.
لدى Krok أيضًا مركز بيانات حول Volochaevskaya ، وقاموا بتوسيع سحابتهم هناك ، وعرضوا نقل جزء من مواردنا هناك. لكن تذكر قصة الكارافان ، التي لم يتم استردادها في الواقع بعد هدم مركز البيانات ، كنت أرغب في أخذ موارد سحابية من مزودي مختلفين من أجل تقليل خطر توقف الشركة عن الوجود (البلد لدرجة أنه من المستحيل تجاهل مثل هذا الخطر). لذلك ، لم يتورطوا مع Volochaevskaya في ذلك الوقت. حسنًا ، هناك بائع آخر يعمل السحر مع الأسعار. لأنه عندما يمكنك الالتقاط والمغادرة بشكل مرن ، فإنه يعطي موقفا تفاوضيا قويا بشأن الأسعار.
نظرنا إلى خيارات مختلفة ، لكن الاختيار وقع على #CloudMTS. كانت هناك عدة أسباب لذلك: أثبتت السحابة أنها جيدة في الاختبارات ، كما أن الرجال يعرفون أيضًا كيفية العمل مع الشبكة (مشغل اتصالات بعد كل شيء) ، وسياسة تسويق قوية للغاية للاستحواذ على السوق ، ونتيجة لذلك ، أسعار مثيرة للاهتمام.
إجمالي 3 مراكز البيانات.
ثم ، بعد كل شيء ، قمنا بتوصيل Volochaevskaya أيضًا - كانت هناك حاجة إلى موارد إضافية ، وفي Compressor كان بالفعل مزدحمًا بعض الشيء. بشكل عام ، قمنا بإعادة توزيع الحمولة بين الغيوم الثلاثة ومعداتنا في Stordat.
4 مراكز بيانات. وبالفعل من حيث الحيوية في كل مكان T3. يبدو أن الجميع ليس لديهم شهادات ، لكنني لن أقول على وجه اليقين.
كان MTS فارق بسيط. لا شيء سوى MGTS يمكن أن يذهب هناك ميلاً أخيرًا. في الوقت نفسه ، لم يكن من الممكن سحب البصريات المظلمة لـ MGTS بالكامل من مركز البيانات إلى مركز البيانات (لفترة طويلة ، إنها باهظة الثمن ، وإذا لم أكن مرتبكًا ، فلن يقدموا مثل هذه الخدمة). كان علي أن أفعل ذلك مع شعاع مشترك وإخراج من مركز البيانات إلى أقرب آبار ، حيث يوجد مزودنا للبصريات الداكنة Mastertel. لديهم شبكة واسعة من البصريات في جميع أنحاء المدينة ، وإذا كان هناك أي شيء ، فإنهم يقومون فقط بلحام الطريق المطلوب ويمنحك مكانًا للعيش فيه. في هذه الأثناء ، جاء كأس العالم إلى المدينة ، بشكل غير متوقع ، مثل الثلج في الشتاء ، وتم إغلاق الوصول إلى الآبار في موسكو. كنا ننتظر انتهاء هذه المعجزة ، ويمكننا أن نرمي رابطنا. يبدو أنه كان من الضروري ترك مركز بيانات MTS مع البصريات في متناول اليد ، الصفير للوصول إلى الفتحة المطلوبة وخفضها هناك. بشروط. فعلوا ثلاثة أشهر ونصف. بتعبير أدق ، تم عمل الشعاع الأول بسرعة كبيرة ،بحلول أوائل أغسطس (أذكر أن كأس العالم انتهت في 15 يوليو). لكن كان عليّ العبث بكتفي الثاني - الخيار الأول يعني ضمناً أنه كان علينا حفر الطريق السريع Kashirskoye ، الذي كان علينا أن نوقفه لمدة أسبوع (كان هناك نوع من النفق في إعادة الإعمار حيث كانت الاتصالات تكمن ، كان علينا حفره). لحسن الحظ ، وجدنا بديلاً: طريق آخر ، وهو نفس الموقع الجغرافي المستقل. تبين وجود عروقين من مركز البيانات هذا إلى نقاط مختلفة من وجودنا. تحولت حلقة البصريات إلى حلقة بقلم.تبين وجود عروقين من مركز البيانات هذا إلى نقاط مختلفة من وجودنا. تحولت حلقة البصريات إلى حلقة بقلم.تبين وجود عروقين من مركز البيانات هذا إلى نقاط مختلفة من وجودنا. تحولت حلقة البصريات إلى حلقة بمقبض.
بالجري قليلاً إلى الأمام ، سأقول أنهم وضعوا لنا على أي حال. لحسن الحظ ، في بداية العملية ، عندما تم نقل القليل. اندلع حريق في بئر واحدة ، وبينما كان المثبتون يشتمون بالرغوة ، في البئر الثاني قام شخص بسحب موصل لينظر إليه (كان الأمر بطريقة ما بطريقة جديدة ، أتساءل). رياضيا ، كان احتمال الفشل المتزامن ضئيلاً. لقد أمسكنا به عمليا. في الواقع ، كنا محظوظين في Fiord - تم قطع مصدر الطاقة الرئيسي هناك ، وبدلاً من إعادة تشغيله ، أربك شخص ما المفتاح وأوقف تشغيل خط النسخ الاحتياطي.
لم تكن هناك فقط متطلبات فنية لتوزيع الحمل بين المواقع: لا توجد معجزات ، وسياسة تسويق قوية بأسعار جيدة تعني معدلات نمو معينة لاستهلاك الموارد. لذا فقد وضعنا في الاعتبار طوال الوقت النسبة المئوية من الموارد التي يجب إرسالها إلى MTS. لقد قمنا بإعادة توزيع كل شيء آخر بين مراكز البيانات الأخرى بشكل متساوٍ تقريبًا.
الحديد الخاص بك مرة أخرى
لقد أظهرت لنا تجربة استخدام السحب العامة أنه من المناسب استخدامها عندما تحتاج إلى إضافة الموارد بسرعة ، للتجارب ، للتجربة ، إلخ. عند استخدامه تحت الحمل المستمر ، فإنه يصبح أكثر تكلفة من لف الحديد الخاص بك. ولكن لم يعد بإمكاننا التخلي عن فكرة الحاويات ، وعمليات الترحيل السلس للأجهزة الافتراضية داخل مجموعة ، وما إلى ذلك. كتبنا الأتمتة لإطفاء بعض السيارات في الليل ، ولكن لا يزال الاقتصاد لا يعمل. لم تكن لدينا الخبرة الكافية لدعم سحابة خاصة ، لذلك كان علينا أن ننميها.
كنا نبحث عن حل يسمح لك بالحصول على سحابة على جهازك بسهولة نسبية. في ذلك الوقت ، لم نعمل أبدًا مع خوادم Cisco ، فقط مع مجموعة شبكات ، كان هذا يمثل خطرًا. تمتلك دلة أجهزة بسيطة ومألوفة وموثوقة مثل بندقية كلاشنيكوف. لقد كان لدينا هذا لسنوات ، ولا يزال موجودًا في مكان ما. لكن الفكرة وراء Hyperflex هي أنه يدعم التقارب المفرط للحل النهائي خارج الصندوق. وفي ديلا كل شيء يعيش على أجهزة التوجيه العادية ، وهناك فروق دقيقة. على وجه الخصوص ، الأداء ليس في الواقع رائعًا كما هو الحال في العروض التقديمية بسبب النفقات العامة. أعني ، يمكن إعدادها بشكل صحيح وستكون فائقة ، لكننا قررنا أن هذا ليس من شأننا ، ودع شركة Dell تعد من قبل أولئك الذين يجدون هذه المهنة. نتيجة لذلك ، اخترنا Cisco Hyperflex. فاز هذا الخيار في المجموع باعتباره الأكثر إثارة للاهتمام: أقل البواسير في التركيب والتشغيل ،وكان كل شيء على ما يرام خلال الاختبارات. في صيف 2019 ، تم إطلاق المجموعة في المعركة. كان لدينا رف نصف فارغ في الضاغط ، مشغول في الغالب فقط بمعدات الشبكة ، ووضعناه هناك. وهكذا ، حصلنا على "مركز البيانات" الخامس - جسديًا ، أربعة ، ولكن اتضح أن تجمعات الموارد هي خمسة.
أخذوا ، حسبوا حجم الحمل الثابت وحجم المتغير. تحولت دائمة إلى حمولة على الحديد. ولكن حتى على مستوى المعدات فإنه يعطي مزايا السحابة من حيث التسامح مع الخطأ والتكرار.
تسديد مشروع الحديد هو متوسط أسعار السحب للسنة.
أنت هنا
في هذه اللحظة ، أنهينا تحركاتنا القسرية. كما ترون ، لم يكن لدينا الكثير من الخيارات الاقتصادية ، وقمنا باستمرار بتحميل ما كان علينا الوقوف لسبب ما. هذا أدى إلى موقف غريب أن الحمل متفاوت. يعد فشل أي مقطع (ويتم الاحتفاظ بالجزء الذي يحتوي على مراكز بيانات Krok على اثنين من Nexus في عنق الزجاجة) خسارة في تجربة المستخدم. أي أنه سيتم الحفاظ على الموقع ، ولكن ستكون هناك صعوبات واضحة في إمكانية الوصول.
كان هناك فشل في MTS مع مركز البيانات بأكمله. كان هناك اثنين آخرين في الآخرين. بشكل دوري ، تسقط الغيوم ، أو نشأت وحدات تحكم السحابة ، أو نوع من مشكلة الشبكة المعقدة. باختصار ، نفقد مراكز البيانات من وقت لآخر. نعم ، لفترة قصيرة ، لكنها لا تزال غير سارة. في مرحلة ما ، من المسلم به أن مراكز البيانات تتساقط.
قررنا الانتقال إلى مستوى تحمل الخطأ لمراكز البيانات.
لن ننام الآن إذا فشل أحد مراكز البيانات الخمسة. ولكن إذا فقدنا كتف كروك ، فستكون هناك عمليات سحب خطيرة للغاية. وهكذا ولد مشروع مرونة مركز البيانات. الهدف هو ذلك - إذا ماتت وحدة تحكم المجال DC ، أو ماتت الشبكة قبلها أو ماتت المعدات ، فيجب أن يعمل الموقع دون تدخل يدوي. بالإضافة إلى ذلك ، بعد الحادث ، يتعين علينا التعافي بانتظام.
ما هي المزالق
الآن:
بحاجة ل:
الآن:
بحاجة ل:
مرونة تقاوم فقدان عقدة واحدة:
من الصعب إدارة قواعد بيانات MySQL (كثير منها صغيرة):
سيكتب زميلي ، الذي قام بالموازنة ، عن هذا الأمر بمزيد من التفصيل. من المهم قبل أن نعلق هذا ، إذا فقدنا السيد ، ثم كان علينا أن نذهب إلى الاحتياطي بأيدينا ونضع العلم r / o = 0 هناك ، ونعيد بناء جميع النسخ المتماثلة لهذا السيد الجديد مع ansible ، وهناك أكثر من اثنين منهم في إكليل الرئيسي العشرات ، قم بتغيير تكوينات التطبيق ، ثم طرح التكوينات وانتظر التحديثات. يمشي التطبيق الآن على anycast-ip واحد ، والذي ينظر إلى موازن LVS. لا يتغير التكوين المستمر. جميع الطوبولوجيا الأساسية على orchestrator.
الآن تمتد البصريات الداكنة بين مراكز البيانات لدينا ، مما يسمح لك بالوصول إلى أي مورد داخل الحلقة لدينا كمورد محلي. وقت الاستجابة بين مراكز البيانات والوقت داخل زائد أو ناقص هو نفسه. هذا فرق مهم من الشركات الأخرى التي تبني الجيوكلاسترز. نحن مرتبطون بشدة بأجهزتنا وشبكتنا ، ولا نحاول توطين الطلبات داخل مركز البيانات. من ناحية ، هذا رائع ، ولكن من ناحية أخرى ، إذا أردنا الذهاب إلى أوروبا أو الصين ، فلن نخرج بصرياتنا السوداء.
وهذا يعني إعادة توازن كل شيء تقريبًا ، وبشكل أساسي قواعد البيانات. هناك العديد من المخططات عندما يحمل المعلم النشط للقراءة والكتابة الحمل بالكامل ، وبجانبه يوجد نسخة متماثلة متزامنة للتبديل السريع (لا نكتب في اثنين في وقت واحد ، أي أننا نكرر ، وإلا فإنه لا يعمل بشكل جيد للغاية). القاعدة الرئيسية في مركز بيانات واحد ، والنسخة المتماثلة في مركز آخر. قد تكون النسخ الجزئية في المرتبة الثالثة للتطبيقات الفردية. هناك من 10 إلى 15 حالة ، حسب الموسم. Orchestrator هو مجموعة ممتدة بين مراكز البيانات و 3 مراكز البيانات. سنخبرك هنا بمزيد من التفصيل عندما تكون هناك قوى لوصف كيفية تشغيل كل هذه الموسيقى.
ستحتاج للحفر في التطبيقات. لا يزال هذا مطلوبًا الآن: في بعض الأحيان يحدث أنه إذا انقطع الاتصال ، فمن الصحيح إطفاء الاتصال القديم ، وفتح اتصال جديد. ولكن في بعض الأحيان تتكرر الطلبات في اتصال مفقود بالفعل في حلقة حتى تموت العملية. آخر شيء تم التقاطه كان مهمة التاج ، ولم يتم كتابة تذكير حول القطار.
بشكل عام ، لا يزال هناك الكثير للقيام به ، ولكن الخطة واضحة.