نحن نصنع أفضل نظام للكشف عن الاقتراض في روسيا والبلدان المجاورة. في عالم مثالي ، سنتعامل فقط مع تصميم وتطوير النظام. ولكن ، للأسف ، لا تعمل مكافحة الانتحال في فراغ ، ولكي يستخدم المستخدمون تطوراتنا بشكل مريح ومريح ، نحتاج أيضًا إلى تطوير البيئة المحيطة بخدمتنا. برنامجنا لا يعمل بدون مكواة حتى الآن ، يحتاج المستخدمون إلى تقديم الدعم الفني ، فمن الضروري تلقي المدفوعات من المستخدمين دون انتهاك القانون ، إلخ. باختصار ، الروتين يكفي.

هذه المقالة هي الأولى من سلسلة من المسلسلات الدرامية عن الإنتاج حول كيفية تحسين خدماتنا مع الاستعانة بمصادر خارجية. نحن نشارك المشاكل الحقيقية والاستنتاجات.

الغيوم ، الخيول ذات الشعر الأشقر ...

^{(من مكان ما على الإنترنت ، رأيته لأول مرة هنا .)}

الحمل على نظامنا غير متكافئ للغاية: أولاً ، خلال اليوم يتغير الحمل 5 مرات. ثانيا ، هناك موسمية واضحة. يتم تخفيض الحد الأقصى اليومي للشيكات بعد نهاية الدورة الصيفية بنسبة 10 مرات! الدورة الشتوية ليست مشرقة جدًا ، ولكنها أيضًا ليست هدية. بالإضافة إلى ذلك ، تكون كل جلسة صيفية لاحقة أثقل (من حيث عدد الاختبارات) وأصعب (تقنيات ووظائف البحث الجديدة) من الجلسة السابقة. لذلك ، من جهة ، أريد أن أحصل على موارد جيدة ، من ناحية أخرى ، لا أدفع أكثر من اللازم أثناء انخفاض النشاط. في إحدى الجلسات ، يمكنك نشر المزيد من الخوادم ، وفي الصيف تقلل كمية الموارد المستهلكة. من الواضح أن هذا هو الحال مع مزودي الخدمات السحابية. في هذه المقالة ، سأتحدث عن جوانب مختلفة من التفاعل مع العديد من موفري السحابة (AWS ، IT Grad ، MCS ، YC). إذا بدا لشخص ما أن هذه صرخة من الروح ، فلن يكون مخطئًا جدًا. لذلك دعونا نذهب!

أوس

بدأنا في استخدام الموارد السحابية في فبراير 2013 عندما استأجرنا خادمنا الأول في AWS. في الواقع ، تعتبر أمازون أول وأطول تجربة لمكافحة الانتحال مع السحب. ثم بدأنا بجهاز واحد ، والآن ميزانيتنا في AWS هي ترتيب أعلى من الميزانية لجميع السحب الروسية. الحب الأول ، كما تعلم ، لا ينسى أبداً. كل المشاكل والفرص مع السحب الأخرى في هذه المقالة فكرت بناءً على تجربة استخدام AWS.

صحيح ، كان هناك أيضا ذبابة في مرهم في العلاقات مع الأمازون. فيما يلي الميزات أو الإزعاجات التي لدينا مع Amazon:

1. لا يمكنك الوصول إلى وحدة التحكم الخاصة بجهاز ظاهري من خلال مستعرض. وأحيانًا تكون هناك حاجة هنا حقًا! بمجرد قيامنا بحذف واجهة الشبكة عن طريق الخطأ ، وفُقد الوصول على أحد الأجهزة. كان من حسن الحظ أن شخصًا ما قد واجه مثل هذه المشكلة بالفعل ، ففي نصف ساعة وجدنا الحل وتطبيقه بنجاح. من خلال وحدة التحكم ، يمكن إجراء هذه العملية في دقيقة واحدة.
2. التكاليف بالدولار ، ونكسب بالروبل. وفقا لذلك ، تعتمد الربحية على الدولار.
3. لا يوجد مركز بيانات في روسيا ، وكان الأقرب عندما بدأنا في أيرلندا. هذا يعني وجود اختبار كبير وبعض القيود على تخزين البيانات التي تنشأ بسبب متطلبات القانون الروسي.
4. Roskomnadzor بانتظام بحظر عناوين AWS. حاليًا ، هناك توفر خادم مختلف في AWS من مواقع مختلفة. لأسباب غير معروفة ، قد يتوقف الاتصال بالجهاز. عادةً ما يساعد تغيير عنوان IP و VPN والوكيل.
5. الأمازون أغلى بكثير من الغيوم الروسية. صحيح ، يمكنك تقليل التكلفة من خلال برنامج نسخ احتياطي مرن واستخدام الحالات الموضعية . ونحن نستخدم بنشاط على حد سواء. للأسف ، لم نر هذه الوظائف حتى الآن في السحب المحلية (محدث: أعلنت YC عن "VMs متوقف" في الرسالة الإخبارية 18 فبراير ، نحن في انتظار التفاصيل).
6. المشكلة مع الرسائل بالمعلومات غير كافية. أثناء الانتقال من الجيل الثالث من الأجهزة إلى الرابعة أو الخامسة ، تغيرت الأجهزة الافتراضية بشكل خطير ، على وجه الخصوص ، طريقة توصيل محركات الأقراص ، ولم تبدأ الأجهزة ببساطة بعد تغيير الكتابة. أرجعت واجهة إدارة المثيل رسالة مختصرة: سعة غير كافية. كانت هناك حدود كافية لإنشاء الأنواع الضرورية من الآلات بهامش ، ولمدة ستة أشهر تقريبًا عذبنا الدعم الفني المجاني على حساب تغيير الحدود. لم يساعد. نتيجة لذلك ، غوغل الحل أنفسهم - يساعد على الترفيه عاديا من الآلات.
7. في بضع مرات ، قمنا بمسح محركات أقراص الحالة الصلبة إلى الثقوب: اختفت الأقراص ببساطة من النظام إلى جانب جميع البيانات. بالنظر إلى أن هذه كانت أقراص سريعة الزوال ، أي يتم فقد البيانات عند توقف الجهاز ، ولم نخزن شيئًا لا يمكن الاستغناء عنه.

من حيث المبدأ ، كان من الممكن التعايش مع هذه العيوب. ومع ذلك ، في الوقت الذي لاحظت فيه Amazon أخيرًا السوق الروسية ، أصبح حسابنا غير مناسب جدًا للدفع من إحدى البطاقات. لحسن الحظ ، سرعان ما قامت شركة Amazon بتصحيح الموقف وتزويدنا بمدير حساب ساعدنا في التحول من الدفع عبر بطاقة إلى عقد مباشر ودفع فاتورة ووضع أنواع مختلفة من الاتفاقيات. بشكل عام ، يأتي بانتظام إلى روسيا ، وعندما يأتي إلينا ، يتحدث عن فرص تحسين البنية التحتية والدفع. في بعض الأحيان يحضر معه مهندس حلول ، يمكنه معه مناقشة الهيكل الحالي لحلنا ، والتحدث عن "قائمة الأمنيات" والمشاكل ، والحصول على العديد من الحلول ، ليس فقط من خلال خدمات AWS. يعلن موظفو Amazon أن هدفهم ليس تقديم المزيد من الخدمات ، ولكن التأكد من أن الخدمات التي تم شراؤها تفيد الأعمال. يبدو أن هذا صحيح حقا. عدد الخدمات وسرعة تنميتها وعمق التكامل المتبادل مثيران للإعجاب. لدى AWS كل شيء لتنظيم عملية التطوير وتشغيل الأنظمة المحملة بدرجة كبيرة من أي نطاق. حتى الآن ، مشكلة عالمية واحدة فقط مكلفة!

IT Grad 2016

في عام 2015 ، قررنا أن الوقت قد حان لكي نتخلى عن الحديد تمامًا. أردت أن أضع المشاكل على موثوقية المعدات على وجه التحديد على الآخرين والتركيز أكثر على تحسين عمليات التطوير الخاصة بنا. وفقًا لتوقعاتنا ، في عام 2016 ، كان لدينا ما يكفي من المعدات التي لدينا الآن ، ونود أن يكون لدينا احتياطي لكل حدث حريق. لقد تعاملنا مع اختيار المزود تمامًا: لقد أعددنا اختبار تحميل واستبيانًا مع أسئلة مهمة بالنسبة لنا واخترناها بدقة من خمسة موفرين: ActiveCloud و Cloud4Y و CloudOne و IT Grad و Softline.

نتيجة لذلك ، اخترنا سحب تكنولوجيا المعلومات غراد. مزاياها:

1. موقف الحياة النشطة ، أعطيت إجابات لأسئلتنا بسرعة ، كان من السهل التواصل.
2. وجود محركات أقراص SSD سريعة ، حتى 30 IOPS لكل جيجابايت. يعد عدد عمليات القراءة العشوائية مؤشرًا مهمًا للغاية بالنسبة لنا ، نظرًا لأن القيم العالية تسمح لنا بوضع وحدات المسح الضوئي لدينا في السحابة.
3. منصة VCloud مع القدرة على التحكم في الآلات ووجود وحدة تحكم لكل جهاز.
4. القدرة على زيادة موارد الجهاز الظاهري دون إعادة التشغيل.
5. الفوترة المرنة - يتم الدفع مقابل الموارد التي كانت قيد الاستخدام في اليوم في منتصف فترة التقرير (في اليوم 14-15 من كل شهر). بالإضافة إلى ذلك ، هناك خيار "الدفع الفوري" ، ومع ذلك ، فهو أغلى ثم يتم حساب كمية الموارد المستهلكة بواسطة متوسط ​​وحدة المعالجة المركزية وذاكرة الوصول العشوائي التي يتم تحميلها كل ساعتين.

في عام 2016 ، انتقلنا إلى IT Grad. إليك ما حدث في ثلاث سنوات غير مكتملة من حياتنا معًا:

1. مرة واحدة كان لدينا مشكلة. بالضبط في الساعة 21:00 بدأ انخفاض غريب في الأداء. انخفض عدد عمليات التحقق التي يمكن للنظام القيام بها من 150 إلى 20-30 في الدقيقة ، بينما بعد بضع ساعات تم استعادة كل شيء وحله بسرعة 600 شيك في الدقيقة. بحثنا لمدة أسبوع في المنزل ، وفحصنا المستخدمين ، واكتشفنا السير ورموز DDoS ، لكننا لم نعثر على أي شيء. لقد تحولنا إلى دعم IT-Grad ، ووجدنا أن "أوه ، ونحن نقوم بعمل نسخ احتياطية هنا." نتيجة لذلك ، حطمونا بمصدر للمشاكل لأنظمة الأقراص المختلفة وأقاموا العمل.
2. عادة ((ميزات استخدام المنتج) ، خلال الجلسة ، تتجاوز حركة المرور لدينا 100 ميغابت في الثانية. غالبًا ما يتم تعيين هذه القيمة افتراضيًا للقناة غير المحجوزة في العديد من موفري الخدمات السحابية. عندما تخطينا هذا الحد لأول مرة ، نشأ عدد من المشاكل: لم تتمكن الحافة المدمجة من التعامل مع VPN بين نقطة الدخول الموجودة على أجهزتنا والجهاز الظاهري لخادم الويب الموجود في السحابة. كما هو متوقع ، تحولوا إلى الدعم ، حيث عرض علينا زيادة الموارد على Edge. حسنًا ، لا شك في أننا استبدلنا تكوينه من صغير إلى كبير ، وقمنا أيضًا بتوسيع القناة إلى حجم حركة المرور القصوى لدينا بهامش. لم يساعد. بشكل عام ، لم نتمكن من العثور على الحل الأمثل ، فقد اضطررت إلى تقليل حجم حركة المرور عن طريق نقل جزء من الإنتاج إلى مواقع أخرى.
3. يتوقف اتصال VPN بموقع IT Grad أحيانًا لمدة 1-2 دقائق. بالنسبة إلى سبب حدوث ذلك ، لا يمكننا نحن ولا الدعم الفني إيجاد الإجابة. حتى الآن لا بد لي من العيش مع هذه المشكلة.
4. تعمل آلية تغيير حجم الموارد بشكل سيئ ، سواء أثناء الطيران أو في حالة عدم التشغيل. يبدو لي ، مع ذلك ، أن هذه مشكلة بالأحرى مع بائع النظام الأساسي (VMware). ومع ذلك ، فقد واجهنا بالفعل حقيقة أنه من أجل تطبيق جميع الامتدادات بشكل موثوق ، كان من الضروري إعادة تشغيل جهاز الضيف (Windows Server 2012 R2). بعد تغيير الحجم ، لم يتم تشغيل الجهاز نفسه عدة مرات. دعم بمجرد إصلاح هذه المشكلة من 2 إلى 4 في الصباح أثناء الجلسة - موسمنا ذاته. كان الجو حارا حتى في الليل!
5. في عام 2016 ، كانت لدينا مجموعة ضخمة ، مثل Everest ، والتي تطلبت الكثير من الموارد. كثيرًا ، كنا في بعض الأحيان نحتاج إلى تجاوز الحد الأقصى لحجم أجهزة الضيوف الموصى بها لمضيف معين. طلب منا الدعم باستمرار لتقليل حجم الأجهزة الظاهرية إلى نصف حجم المضيف على الأقل. يجب أن نشيد بتقنية IT Grad - فقد عرض علينا أن نستخدم جهازًا منفصلًا مع إمكانية استخدامه بالكامل ، مقابل بضعة أموال كبيرة أخرى ، وفقدت مرونة السحابة.
6. لعبت الفوترة مرة واحدة في الشهر لقياس كمية الموارد المستهلكة خدعة علينا مرتين. في البداية ، سألنا مباشرة عن فرصة خفض الموارد في 14-15 من الشهر من أجل دفع أقل. تم الرد علينا مباشرة أن هذا هو كيف يعمل. في المرة الأولى التي ضربتنا مؤلمًا أثناء نقل جزء من البيع إلى السحابة الخاصة بنا. العامل البشري يعمل - لقد حاولوا الانتهاء بسرعة من كل شيء بحلول الرابع عشر ، ثم قاموا بهز بشكل ملحوظ. في المرة الثانية التي انتهزنا فيها هذه الفرصة بعد ما يقرب من 3 سنوات من التعاون ، وبعد ذلك تم تقييم فواتيرنا في اليوم الخامس والخامس عشر والعشرين. ثم عمل العامل البشري لصالحهم - بعد المكالمة اتضح أنهم ارتكبوا خطأ في مصلحتهم (تم إعادة الحساب يدويًا) ، اعتذر ، أعطى خصمًا.
7. أداء الأقراص والآلات ككل تلبية الخصائص المعلنة. ومع ذلك ، عدة مرات لم نفهم لماذا كان كل شيء يعمل ببطء شديد ، حتى تباطأت الواجهة بلا رحمة. أكد الدعم أن كل شيء كان على ما يرام وليس لديهم مشاكل مع المعدات. ما حدث هناك - انتقل خادمنا في تلك اللحظة إلى مضيف مجاور أو قام شخص ما بعمل نسخة احتياطية من النظام الفرعي للقرص - يظل لغزًا بالنسبة لنا.
8. يمكن تبديل الأقراص بين الآلات بشكل مستقل فقط من خلال الدعم. في بداية الاستخدام ، كان من المستحيل وجود أقراص من أنواع مختلفة في الجهاز ، وكان عليك الخروج (iSCSI و Samba و NFS). بعد مرور بعض الوقت ، أصبح استخدام أنواع مختلفة من الأقراص في جهاز واحد ممكنًا أولاً من خلال الدعم ، ثم من تلقاء نفسه (يبدو أنه تم في vCloudDirector). بالمناسبة ، يحدث تحديث نظام إدارة الافتراضية بشكل منتظم. نتلقى خطابًا 1-2 مرات في الشهر يفيدنا بأن نظام التحكم في الجهاز الظاهري يستغرق لمدة ساعة أو ساعتين العمل الفني ولن يكون متاحًا لبعض الوقت ، وتواصل الأجهزة نفسها العمل في هذا الوقت.
9. في 16 شباط (فبراير) 2018 ، كان جزء من مبيعاتنا الموجودة في IT Grad يرجع إلى مشاكل في إمداد الطاقة بمركز البيانات الذي يوجد به الجهاز. علمنا بالحادث الفعلي ؛ لم نتمكن من الاتصال بالدعم الفني. اضطررت إلى الاتصال بمدير الحساب لدينا ، وقال على الفور في دقيقة واحدة ماذا وكيف ، وانقطع الاتصال ، على ما يبدو يقول البقية. من السعادة - كنا نكذب بجانب فكونتاكتي.

بعد قضاء بعض الوقت في منزل مستأجر وتواجه كل ما سبق ، قررنا في عام 2017 أنه من الجيد الزيارة ، ولكن كان ذلك أفضل في المنزل ، وبدأنا في صنع سحابة مع أقراص NVMe سريعة والقدرة على التحكم الكامل في كل شيء. لم يجرِ قول ما حدث بعد ذلك: لقد نقلوا المبيعات إلى السحابة الخاصة بهم من عملاء الشركات ووحدات البحث (في المجموع أكثر من 90 ٪ من الحمل) ، وترك المراقبة والإحصاءات والعملاء من القطاع الخاص في تكنولوجيا المعلومات غراد. في عام 2018 ، احتسب الجميع مرة أخرى واتضح أنه كان أكثر ربحية تقسيم الإنتاج: الحفاظ على جزء في السحابة المؤجرة ، وجزء من جانبهم. ما جاء من هذا - نقول المزيد.

حلول البريد السحابية

بصراحة ، أردت ، كما هو الحال في AWS ، ولكن في روسيا. لذلك ، بدأنا نتطلع إلى السحب مع مجموعات متشابهة من الخدمات (الذي أخدعه ، على الأقل من خلال التناظرية بين EC2 و S3). كان البحث قصير الأجل - وجدنا "الأمازون الروسي" في شخص MCS . شركة كبيرة مع مجموعة واسعة من الخدمات المتنوعة ، من خلال جميع المؤشرات التي ينبغي أن تكون قادرة على إعداد الغيوم!

كانت بداية التعارف رائعة. جاء مدير حساب إلى مكتبنا ، وأخبرنا بكل شيء بالتفصيل ، ووصف الفرص والخطط الحالية في المستقبل القريب. كان الإخراج صورة رائعة: انخفاض أسعار موارد الحوسبة ، وهناك تخزين كائن والخروج المبكر لإنتاج قاعدة البيانات (على غرار RDS). لقد منحنا أيضًا حدًا نقديًا قويًا للاختبار (أكثر مما يعطيه Azure).

بحلول ذلك الوقت ، كان لدينا بالفعل جزء IaC جاهز لنشر جميع الأجهزة من خلال terraform. وكان MCS openstack وكان مدعوما جيدا! بالمناسبة ، يتم تقديم الدعم الفني من خلال قناة التلغراف - التواصل "المباشر" ومن الواضح أنهم يريدون المساعدة. يوجد نظام التذاكر ، لكننا لم نستخدمها بعد. يشير الدعم الفني SLA إلى الطلبات التي تم إنشاؤها في نظام التذاكر.

بحلول ديسمبر 2018 ، كتبنا نصوصًا لنشر البنية التحتية عبر terraform. حان الوقت للتحرك. بادئ ذي بدء ، قررنا نقل النظام مع العملاء من القطاع الخاص ، والذي عاش كل هذا الوقت على المعدات في تكنولوجيا المعلومات غراد. ثم كل شيء مثل في فيلم:

7 (), 18:00 . , .
10 (), 10:00 – .
12 () – .
10:00 terraform. , , .
12:00 ansible'. . !
15:30 . 30 , 16:30.
15:45 . .
15:55 . : , .
16:20 , . , . , - .
17:30 , , .
18:00 . 1,5 .


لا يجب أن تظهر المشكلة المحددة بتنسيقات مختلفة مع محاولة جديدة ، ولكن وجدناها وفقط في حالة إصلاحها.

17 (), .
15:30 . , .
16:00 . .
16:30 , 100%. -? !
17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. .
21:45 , , , 2000 .
22:00 , .


همز القديم على تكنولوجيا المعلومات غراد بسهولة تلبية الطلب المؤجل لفحص المستخدم ، لا مشكلة.

في اليوم التالي (18 ديسمبر) ، أدركنا ما يلي:

1. لم نكن نعرف ما الذي أبطأ النظام على وجه التحديد. قبل الإفريز ، لم يكن هناك أي حمل عمليًا في أي مكان. نعم ، لا يزال لدينا مكالمات حظر عميقة داخل النظام ، وعلى الأرجح يوجد حظر في مكان ما ، لكن أينما لم نتمكن من الخروج بالضبط ، كان من الضروري إجراء مزيد من التحقيق.
2. اختبار الحمل الحالي الخاص بنا لم يتطابق مع ملف تعريف التحميل الخاص بـ prod. كان رائعا ل بفضل هذا الاختبار ، أعددنا للدورة الأخيرة وحددنا عددًا كبيرًا من الاختناقات وأزلناها. ولكن هذا هو الواقع - من الضروري إعادة الاختبار مع مراعاة الخبرة المكتسبة.
3. تم إنتاجه بتقنية IT مع موارد وحدة المعالجة المركزية (RAM) وذاكرة الوصول العشوائي (RAM) القابلة للمقارنة ، يمكنه بسهولة التعامل مع ضعف الحمل.

لذلك ، قمنا ببناء اختبار يحقق النتيجة نفسها التي رأيناها مباشرة. لقد ذهبنا إلى دعم MCS لمعرفة ما إذا كنا نتناول حدًا معينًا لوحدة المعالجة المركزية ، ولكن بشكل عام هو خاص بنا أم لا ، وهو كل شيء على ما يرام مع الشبكة. ما زالوا لم يجيبوا على السؤال الثاني ، لقد وجدوا شيئًا على السؤال الثالث وأوصونا بإجراء تغييرات على الأنظمة متعددة النواة. بشكل عام ، قمنا بتطوير نشاط نابض بالحياة ، اقتربت نهاية العام ، والجميع يريدون المغادرة لقضاء العطلات مع شعور بالإنجاز.

إليك ما انتهينا إليه أثناء العمل مع MCS:

1. حتى في مرحلة الاختيار ، تم إرسال جدول يحتوي على خصائص الأجهزة الافتراضية وجيش تحرير السودان حسب القرص. كان من بين الإيجابيات أنها وعدت بـ 50 IOPS / GB (IT Grad: 30 IOPS / GB) من أجل SSD. اتضح أن العقد مختلف: "القراءة: 5000 IOPS ، الكتابة: 2000 IOPS" ، وقد فاتنا ذلك ، لم نكن نتوقع ذلك. الجداول متطابقة ، والفرق في مكان واحد فقط! بالمناسبة ، لم نر تبعيات الأداء على حجم القرص. عندما اختبرنا ، اتضح أنه مع محرك أكبر ، تنخفض السرعة. يكمن سر هذه المؤشرات الصغيرة في أن MCS لديها هاتف موزّع جغرافيًا ، مما يعني أنه إلى أن تقول العقدة البعيدة أن البيانات قد كتبت ، لن يتم إخبار العميل بأن التسجيل قد اكتمل. بالمناسبة ، لا يبدو أن هناك من يمتلك هذه الموثوقية "خارج الصندوق" بين مقدمي الخدمات الذين تحدثنا إليهم. ولكن بالنسبة لنا هذه الموثوقية تضع العصي فقط في العجلات! في حالة حدوث شيء ما ، نحتاج إلى الانتقال سريعًا إلى منطقة أخرى عند حدوث المشاكل ، وبالتالي لدينا النسخ المتماثل غير المتزامن الخاص بنا. لدينا DRP ، ونحن على استعداد لفقدان كمية صغيرة من البيانات في حالة وقوع حادث. يجب أن نشيد MCS ، فقد عجلوا في تشغيل صفيف SSD محلي ، وكان أدائه أعلى من ذلك بكثير.
2. أما بالنسبة لمعايير الآلات ، فهي ليست تعسفية. هناك مجموعة معينة من CPU-RAM- {SSD / HDD} (كما في AWS تقريبًا) ، ولا يمكن إنشاء أنواع أخرى من الأجهزة إلا من خلال الدعم. تستغرق العملية برمتها حوالي ساعتين ، ولا يوجد حد لعدد الأنواع ، والشيء الرئيسي هو أن عدد النوى يجب ألا يزيد عن نصف المعالج من برنامج Hypervisor ~ 40-48. أثناء إنشاء الجهاز ، يمكنك إضافة أقراص بنفسك وتبديلها بين الأجهزة.
3. بعد تشغيل SSD المحلي ، جعل تغيير معلمات الجهاز من المستحيل تشغيله. لا يمكن إطلاقها إلا من خلال الدعم. في مكان ما في شهر حلوا المشكلة.
4. لأول مرة تواجه الدعم الفني من قبل برقية. بشكل عام ، إنه مناسب ، خاصةً في البداية ، عندما يكون هناك الكثير من الأسئلة ويتعرف على الخدمة. ولكن كلما زادت صعوبة طرح الأسئلة وانخفضت سرعة الرد ومحتوى المعلومات ببطء. بحلول نهاية العام ، عندما ، بالطبع ، كانت المواعيد النهائية المحددة للجميع ، كانت السرعة المنخفضة للردود قد أغضبتني بشدة. في مرحلة ما ، سألوا حتى عن SLAs. هذا هو المكان الذي جاء فيه فهم أن جيش تحرير السودان في نظام التذاكر ، وليس في البرقية! في وقت 19 فبراير ، تم تعليق العديد من أسئلتنا التي لم تتم الإجابة عليها في 24 ديسمبر في هذه القناة ...
5. لا يأخذ الدعم الفني من خلال نظام التذاكر في الاعتبار أننا قد قمنا بتسجيل الدخول ، ويتطلب إشعارًا إضافيًا برقم العقد. رداً على ذلك ، يرسل خطابًا "سنتصل بك" ، لكنه لا يشير إلى رقم التذكرة أو حالتها.

أثناء العمل مع MCS ، بدأت سحابة أخرى في النظر بالتوازي.

سحابة أخرى (Yandex Cloud)

وكان أول من الآخرين ياندكس. في نهاية عام 2018 ، كان لديهم فقط الأجهزة الظاهرية وتخزين الأشياء وقذيفة نظام المحاكاة الافتراضية الخاصة بهم وواجهة برمجة التطبيقات المفتوحة. وكان البرنامج المساعد terraform في ألفا ووافقت عليه HashiCorp. الدعم ، كالعادة ، يتم عبر البرق ، لكنه أقل نشاطًا منه في MCS. حد المال المخصص للاختبار صغير بدرجة كافية ولم يسمح لنا بإجراء الاختبارات العادية. اضطررت إلى إبرام اتفاق على عجل (3 أيام عمل) ودفع ثمن الاختبار. وفقا لنتائج الاختبار ، حصلنا على نفس الشيء على MCS. لقد بدا لنا أن هناك مشكلتين: كل شخص لديه محركات بطيئة للغاية ، ولدينا اختبار شديد للغاية.

IT Grad 2019

بشكل عام ، حددنا موعدًا نهائيًا للانتقال بالفعل في 22 ديسمبر ، بحيث يكون هناك أسبوع آخر لتحديد وحل المشكلات الخفية لإقامة جديدة. بعد أن فقدنا الأمل في الانتقال إلى الموعد النهائي وتعبنا قليلاً من وفرة المعلومات الجديدة في شخص MCS و YC ، قررنا أن IT Grad ليس سيئًا جدًا على خلفيتهم. شعرنا حتى بالحنين إلى حد ما وفكرنا في أن كل شيء جديد قديم جدًا. بالفعل في IT Grad سنعمل بشكل جيد بالتأكيد - هناك سابقة. ضخ IT-Grad الإضافي: كان هناك مركز بيانات في موسكو ، المستوى الثالث ، وقت التشغيل في الوقت الحالي لا يزال لديه 100٪ (لم يفشل أبدًا) ، والمعدات من الداخل - 4 مقابس Intel Xeon Scalable (حتى 42 مركزًا × 3 غيغاهرتز زيون الذهب 6154). ماذا بحق الجحيم لا يمزح ، إعطاء فرصة ثانية!

28 (), 18:10 - vDC , , .
29 ( ), 17:04 , . .iso , . , . , . , .
30 (), 22:00 , .iso, . , - .
31 (), 3:15 Edge vDC vDC. , . .

, .

2 (), 15:30 .
2 (), 21:50 , Guest OS Customization .
3 (), 18:05 !

1. الآن ، أثناء إعداد المقال ، وجدوا أن الوقت المحدد للطلبات والإجابات لا ينعكس في نظام التذاكر. بدلاً من ذلك ، تقول "منذ حوالي شهرين" ، يتم عرض الوقت المحدد فقط في تلميح الأدوات. عبر البريد ، من الصعب أيضًا استعادة تسلسل الأحداث. تأتي الرسائل المرسلة إلى البريد في منطق غير واضح ولا تحتوي على وصف للإجراء. يتم إنشاء التذاكر في النظام بعد مرور بعض الوقت نيابة عن موظف دعم فني في IT Grad.
2. بعد إلقاء نظرة فاحصة على المعدات بعد العطلة ، رأينا زيون v2 هناك. هذا ليس ما اتفقنا عليه. حسنًا ، لقد قررنا هذا السؤال مع مدير الحساب. كانت هناك بعض الصعوبات بسبب حقيقة أنه في عام 2019 الجديد تم تضمين IT Grad في النظام التجاري المتعدد الأطراف ، وبعد العطلة مباشرة كانت هناك فوضى بسيطة. من vDC على معدات جديدة في العاصمة موسكو لم يكن مرئيا vDC التي تم إنشاؤها قبل العام الجديد. من خلال الإنترنت المفتوح فقط ، سرنا الدعم الفني بأن سرعة الحركة لا تتجاوز 1 تيرابايت / يوم. وقمنا بالفعل بتحميل 7 تيرابايت من البيانات! نتيجة لذلك ، قاموا بإنشاء تطبيق للتنقل مساء الخميس. بعد يوم ، مساء يوم الجمعة ، سألت كيف حالك ومتى يخططون للبدء (الانتظار لمدة أسبوع تقريبًا!)؟ بعد يوم ، مساء السبت ، قيل لنا أن جميع السيارات قد تحركت. لم يعجبني ذلك ، ولم يكن هناك أي معلومات عن التقدم المحرز في العمل لمدة 2.5 يوم ، وأن تقديرات الحركة كانت متشائمة للغاية.
3. في سبتمبر 2018 ، عندما بدأنا تطبيق IaC ، أدركنا أن terraform يعمل بشكل سيء للغاية مع vCloudDirector (محدث: في وقت كتابة هذا التقرير ، علمنا أن VMware vCloud Director Provider 2.0 ظهر ، لكننا لم نجربه بعد). في البداية ، لم نتمكن حتى من إنشاء جهاز نظرًا لحقيقة أن vCloud أبلغنا بوجود خطأ بروح "حدث خطأ ما ، لديك خطأ قدره 512 حرفًا 136 سطرًا (كان الخط أقصر!) Xml من تكوين الجهاز". طلبنا الدعم. تمت إعادة توجيه السؤال إلى المهندسين ، وفي النهاية تم إخبارنا بأن terraform غير مدعوم - قم بفرز ذلك بنفسك. على أي حال ، لقد توصلنا إلى أن الرازم كان مسؤولاً ، حيث جمعنا صورة الجهاز ، لم يستطع التعامل مع تنسيق تهيئة VMware الخاص. Terraform سيء للغاية مع vCloudDirector ، كل شيء مترابط ببطء ، وتم التخلي عن الموصل لفترة طويلة ولا يتطور. لا أحد سوف يتيح لنا الوصول إلى vSphere. إذا بقيت على برنامج VMware ، فأنت بحاجة إلى رؤية الأتمتة من خلال واجهة برمجة التطبيقات.

قمنا بتنظيم مقعد اختبار في موقع جديد. كانت النتيجة مذهلة - فشل الاختبار ، والأعراض هي نفسها كما في MCS. ربما ، في الاختبار الحالي في خضم المعركة للدورة ، تم تغيير بعض إعدادات نظام التشغيل التي تمنع النظام من التجمد ، ولكن لا يمكن استعادتها الآن. لمنع هذا من الحدوث مرة أخرى ، نعرض IaC. لقد أجرينا اختبارين إضافيين: إنشاء آلات جديدة من صور نظيفة لأنظمة التشغيل الخاصة بالبيع الحالي - الفشل ؛ على آلات الإنتاج الحالية - النجاح. وبالتالي ، تم التأكيد على أننا قمنا ببعض الضبط في نظام التشغيل أو قاعدة البيانات ، لكننا لا نتذكر أيها. عند هذه النقطة ، وصل الحل من تطويرنا في الوقت المناسب: تتوقف أفاريز عندما يتم تعطيل جلسات موثوقة في WCF.

لقد أجرينا اختبار تحميل بالإعدادات التي أوصى بها المطورون بالتوازي على MCS (2 جيجاهرتز و Xeon v4) و IT Grad (3 جيجا هرتز و Xeon v2) - عدد المراكز والذاكرة هو نفسه. في MCS ، اجتاز الاختبار بشكل أسرع (بمقدار الربع) وأكثر سلاسة (في IT Grad ، أصبح الاختبار متشنجًا ، ثم أسرع ، ثم أبطأ).

مقارنة أداء القرص

لقد كنا مهتمين بشدة بأداء الأقراص لقواعد البيانات والفهارس ، وهذا هو السبب في أننا اختبرنا محركات أقراص الحالة الثابتة بشكل أساسي. لا تحكم بشكل صارم على الاختبارات ، عندما كنا بحاجة لفهم أداء السحب ، على habr.com لم تكن هناك عدة اختبارات للأقراص ، والمعالجات ، ومزودي السحابة ( مرة ، اثنان ) حتى الآن. لقد كنا محدودين في الوقت المناسب وكان علينا أن نقارن الأداء بسرعة من أجل الحصول على فكرة عن الفرق في الأداء. لذلك ، كان الشرط للاختبار واحد - يمكن أن تتكرر بسرعة في أي موقع. استخدمنا الآلات في أقرب وقت ممكن من المعلمات التي قمنا بنشرها بالفعل ، لاختبار أداء الأقراص و pgbench - لتقييم أداء قاعدة البيانات على هذا القرص. كمعيار ، أخذنا قياسات من الإنتاج الحالي - MARS (لأن معداتنا تحمل اسم أبطال السلسلة المتحركة حول الفئران الصخرية من المريخ ).

عادة ، يعتمد أداء القرص على حجمها. لاحظنا هذا السلوك في IT City وفي AWS ، لكن في MCS لم نر هذا الاعتماد ، كما أنه غير موجود في SLA ، وقد أعطت الاختبارات نتيجة متناقضة (وربما غير دقيقة) - انخفاض الأداء مع زيادة القرص.

عدنا iops لأقراص HDD و SSD ، وكذلك tps (المعاملات في الثانية) لقاعدة بيانات postgres على أقراص SSD. يوجد نوعان من الأقراص في MCS: محركات أقراص الحالة الثابتة الموزعة جغرافيًا ومحركات الأقراص الصلبة ومحركات أقراص الحالة الثابتة المحلية (فقط في وحدة تحكم واحدة) (يتم عرض أدائها بين قوسين). أيضًا في يناير 2019 ، في رسالة بريدية من MCS ، قرأنا أنهم زادوا من أداء القرص بنسبة 20٪ ، وكانت نتيجة الاختبار أيضًا في الجدول (MCS 2019). في فبراير ، تم الإبلاغ عن تسارع آخر ، لكننا لم نجر اختبارات هنا.

النتائج:

منهجية الاختبار

تم حساب iops على أنه متوسط ​​4 fio يعمل:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps ، في المتوسط ​​3 يدير pbbench:
pgbench -c 10 -j 2 -t 10000 example

وصف المدرجات

المريخ

Xeon v4، 2 GHz ؛ HDD: ceph ، 3 عقد من 9x 2 تيرابايت ST2000NX0253 ، نسخة طبق الأصل 2 ؛ SSD: ceph ، 3 عقد على 2 تيرابايت NVMe Intel DC P4600 ، نسخة طبق الأصل 2

وحدة المعالجة المركزية : 4 ، ذاكرة الوصول العشوائي : 8GB ، الأقراص الصلبة : 32GB ، SSD : 150GB ؛ الإنتاج الموازي هو الغزل.

غراد تكنولوجيا المعلومات

Xeon v4 / v2 ، 2 جيجاهرتز ؛ الأقراص الصلبة : 0.1 IOPS / GB ؛ SSD: 30 IOPS / GB

وحدة المعالجة المركزية : 4 ، ذاكرة الوصول العشوائي : 4GB ، الأقراص الصلبة : 250GB ، SSD : 200GB

ام سي اس

زيون v4 ؛ HDD: r / w: 1500/1000 IOPS ؛ SSD: r / w: 5000/2000 IOPS

لاختبار الأقراص الصلبة: وحدة المعالجة المركزية : 2 ، ذاكرة الوصول العشوائي : 4GB ، الأقراص الصلبة : 50GB

لاختبار SSD ، TPS : CPU : 8 ، RAM : 16GB ، SSD : 600GB

Y

زيون v4 ، 2 جيجا هرتز

وحدة المعالجة المركزية : 8 ، ذاكرة الوصول العشوائي : 8GB ، الأقراص الصلبة : 20GB ، SSD : 50GB

مقارنة تقديرات التكلفة الإجمالية للملكية للعام

عدنا التكلفة الإجمالية للملكية لأربعة خيارات. يتم عرض القيم النسبية في الجدول أدناه. يجب أن أقول أن هذا هو حساب لحالتنا المحددة ، وقد يتحول كل شيء بشكل مختلف بالنسبة لك.

فعلنا الحساب على النحو التالي. تم تقسيم السنة إلى قسمين: الجلسات (مع زيادة عبء العمل) وبقية الوقت. لكل جزء ، تم حساب الكمية المطلوبة من موارد وحدة المعالجة المركزية وذاكرة الوصول العشوائي. حجم القرص المطلوب ، نظرًا للنمو المستمر للخدمة ، لا ينمو إلا بمرور الوقت ، لذلك أخذنا المتوسط ​​بين بداية ونهاية العام للتقييم.

كان هناك صعوبة تذكر في التقييم مع AWS ، كما لا توجد تكلفة مباشرة على kernel وجيجابايت من الذاكرة. لقد اتخذنا 3 أجهزة كحد أدنى c5.large ، r5.large و m5.large وحسبت تكلفتها بأسعار MCS (تغيير نسبيًا تكلفة وحدة المعالجة المركزية (CPU) ، حيث أن MCS لديه تردد 2 جيجاهرتز). اتضح مثل هذا: في المتوسط ​​، تكلفة مثيلات AWS البسيطة أعلى بنسبة 2.5 إلى 2.8 مرة من تكلفة MCS. AWS تنشر الأسعار دون ضريبة القيمة المضافة. لذلك ، بالنسبة لتكلفة AWS نضيف 20 ٪ ، ومتوسط ​​سعر الدولار السنوي هو 70 روبل. تعتبر الأقراص ببساطة شديدة بأسعار EBS (نستخدم أنواعًا مختلفة من gp2 و sc1 و st1). في بعض الأماكن ، نحتاج إلى محركات أقراص NVMe من مثيلات عائلة i3. يتم حساب السعر لكل غيغابايت ببساطة شديدة: الفرق في التكلفة بين i3 والمعالج المماثلة والذاكرة من عائلة r4 ، مقسوما على كمية NVMe. اتضح 3.1 روبل لكل جيجابايت في 30 يوما.

حتى في المحادثة حول الميزانيات ، أود أن أشير إلى الفرق في تكلفة ترخيص Windows لكل كور واحد شهريًا لجميع مزودي الخدمات السحابية. في AWS ، يكون الفرق بين تكلفة Linux OnDemand و Windows OnDemand مقسومًا على عدد النوى ثابتًا بحوالي 2800 روبل شهريًا. في YC ، يكون ترخيص Windows لـ kernel أرخص بثلاث مرات ، وحوالي 900 روبل في الشهر ، وفي MCS ، أرخص بنحو 9 (!) Times ، وحوالي 300 روبل في الشهر. لا نزال نعتمد اعتمادًا كبيرًا على نظام التشغيل Windows: الآن ، وبفضل .net core ، بدأنا في جعل نظام مكافحة الانتحال متقاطعًا ، بما في ذلك تقليل تكلفة الصيانة.

التكلفة الإجمالية لل YC تشمل أيضا تكلفة حركة المرور.

الاستنتاجات

من خلال الغيوم

AWS يقولون أنه يوجد في روسيا 4 موفري خدمات سحابية جيدة: AWS و GCP و Azure و DO ، وجميعهم ليسوا في روسيا.
المميزات: خدمة رائعة ، معدات حديثة عالية الجودة ، تهيئة جيدة في EC2 ، عدد كبير من الخدمات.
العيوب: باهظة الثمن (بالإضافة إلى مخاطر سعر الصرف) وليس في روسيا (ILV ، جدار الحماية الروسي العظيم في الأفق). أريد حقًا أن تتبع السحب لدينا هذا المثال.
الميزات: يمكن للدعم الفني المجاني أن يحل الحد الأدنى من المشكلات ، ولكن بصراحة ، اتصلنا بها فقط لتوسيع حدود الاستخدام. المدفوعة ، بالمناسبة ، يكلف حوالي 10 ٪ من الحساب.

غراد تكنولوجيا المعلومات . خدمة جيدة لسحابة الشركات. هناك نظائرها من EC2 و S3 على أساس سويفت.
الايجابيات: أداء جيد (1-2-3 GHz CPU ، SSD ، HDD) ، معدات جديدة (في واحدة من DC) بين الغيوم المحلية ، تكوينات الجهاز التعسفي.
العيوب: الفواتير غير المفهومة ، برنامج VMware (ضعيف التشغيل الآلي ، واجهة الفلاش) ، قليل من الفوضى والتلاعب في الدعم الفني.
الميزات: شحذ أكثر تحت استخدام الشركات (بمجرد التهيئة ، ثم تغييرات نادرة) من تحت نظام عام محمّل للغاية (تحديثات متكررة ، تغييرات مستمرة). منذ عام 2019 ، تم بيع أعمال IaaS مع الأشخاص والمعدات في MTS ، والآن يمكن تغيير كل شيء في أي اتجاه. التواصل من خلال نظام التذاكر والهاتف ، أود الحصول على رد فعل أسرع ورسالة المواعيد النهائية المتوقعة.

MCS . هناك نظائرها في خدمات EC2 (هناك وحدات معالجة الرسومات) ، S3 ، ECS ، RDS ، EMR ، خدماتهم الخاصة: التعلم الآلي ، استرداد الكوارث في الحوسبة السحابية ، النسخ الاحتياطي
الايجابيات: غير مكلفة ، النامية بنشاط ، هناك GPUs (تسلا V100 و Grid K2).
سلبيات: محركات الأقراص البطيئة ، رطبة ، كارما سيئة من الشركة الأم.
الميزات: الدعم الفني في البداية مفيد ، وهناك عدد كبير من الموظفين قيد التشغيل ، وشعور المساعدة ، ولكن بعد ذلك كان هناك انخفاض ملحوظ في النشاط (لم يردوا على أي شيء منذ 24 ديسمبر ، وأنا قلق حتى حول اللاعبين).

YC . لدينا خبرة قليلة جدًا في العمل مع هذا المزود ، من الصعب أن نقول أي شيء محدد. هناك نظائرها من EC2 ، S3 ، RDS ، DS ، SQS (ألفا) ، ELB (ألفا) ، خدماتها الفريدة: SpeechKit ، ترجمة.
الايجابيات: محركات الأقراص هي أسرع من MCS.
سلبيات: مزود terraform رطب. إن برنامج shell virtualization with open api ليس كبيرًا جدًا للمجتمع ، مما يعني أنه حتى الآن يمكنك الاعتماد فقط على نقاط القوة لفريق YC في تطوير مزود terraform.
الميزات: دفع لحركة المرور.

الدروس المستفادة

1. لقد أدركنا أن اختبارات الإجهاد قديمة. قاموا بتحديث الاختبار ، ووجدوا اختناقات جديدة ، وثبتها ، وجعلوا المنتج أفضل. لقد تذكرنا أن اختبار التحميل يجب أن يكون كافيًا ويجب أن يكون هناك تكوينات لا يمكن أن يمر عليها بالتأكيد حتى تتمكن من رؤية الحد الأقصى للتطبيق.
2. على الرغم من الاعتقاد السائد بأن البرامج لا يتم تحسينها في الوقت الحالي ، وأن جميع الاختناقات تغمرها الموارد ، كان علينا اكتشاف نظامنا وتحسينه. اتضح أنه أفضل مما كان عليه ، الإصدار الجديد من مكافحة الانتحال يتطلب موارد أقل ويعمل بشكل أسرع. حددت بالفعل عدة أماكن أخرى حيث يمكنك تقليل استهلاك الموارد.
3. لقد قمنا بـ IaC ونشره وتحديثه من خلال ansible ، وتعلمنا كيفية الانتقال من السحابة إلى السحابة (مع تكرار البيانات الأولية) في حوالي 10-15 دقيقة. إذا تم نسخ البيانات وتم تكوين النسخ المتماثل بشكل منتظم ، فهنا هي "خطة استرداد الكوارث": التحرك خلال نصف ساعة مع فقد البيانات في آخر 15 دقيقة.

ماذا نريد من السحب

1. إجابات سريعة من الدعم الفني. لسوء الحظ ، لا يمكننا استخدامه كما في AWS ، حتى الآن - هناك القليل من المعلومات المتاحة.
2. دعم لأتمتة نشر البنية التحتية عن طريق الأموال المجانية (terraform).
3. القدرة على التنبؤ في الأداء. وهذا ينطبق على الفواتير ، وأداء وحدة المعالجة المركزية ، ذاكرة الوصول العشوائي ، والأقراص.
4. وجود نظائر وظيفية EC2 ، S3 ، RDS الآن. في المستقبل القريب ، نحتاج إلى دعم لحسابات k8 و GPU (نستخدمها بالفعل على AWS).

بالإضافة إلى الانتقال إلى السحب ، خلال الأشهر القليلة الماضية تمكنا من لمس أشعل النار في مناطق أخرى. كيف كان - سنقول قليلا في وقت لاحق.