منذ ما يقرب من 20 عامًا ، تقدم Google أنظمة معقدة وواسعة النطاق بشكل لا يمكن تخيله وحساسة لطلبات المستخدمين. يعثر محرك بحث Google على الإجابة عن أي أسئلة في جزء من الثانية ، وتعكس خرائط Google بأعلى دقة المشهد الأرضي ، ويتوفر بريد Google في وضع 365/24/7 ، وبصورة أساسية ، أصبح التخزين السحابي العام الأول. هل هذه الأنظمة لا تشوبها شائبة؟ لا ، إنهم يفشلون أيضًا ، ويتعطلون ويصبحون عفا عليها الزمن ، مثل أي معدات. نحن فقط لا نلاحظ ذلك. الشيء هو أنه منذ أكثر من عشر سنوات ، تعمل Google على تطوير تقنية هندسة موثوقية الموقع الفريدة ، والتي تضمن التشغيل المتواصل والتطوير التدريجي لأنظمة البرامج بأي تعقيد. هذا الكتاب عبارة عن مخزن خبرة تراكمته Google على مدار سنوات عديدة ، وهو عمل جماعي للعديد من المتخصصين البارزين ومورد لا غنى عنه لأي مهندس يريد تطوير وصيانة أي منتجات بأعلى جودة وأكثر كفاءة.
SRE جوجل من حيث SRE
تختلف مراكز بيانات Google (مراكز البيانات) اختلافًا كبيرًا عن مراكز البيانات التقليدية و "مزارع" الخوادم الصغيرة. تقدم هذه الاختلافات مشاكل إضافية وفرصًا إضافية. يناقش هذا الفصل التحديات والفرص الخاصة بمراكز بيانات Google ويقدم المصطلحات التي سيتم استخدامها خلال الكتاب.
المعداتتقع معظم موارد الحوسبة في Google في مراكز البيانات التي صممتها الشركة ، والتي لديها نظام إمداد الطاقة الخاص بها ونظام التبريد والشبكة الداخلية ومعدات الحوسبة [Barroso et al.، 2013]. على عكس مراكز البيانات النموذجية التي يوفرها مقدمو الخدمة لعملائهم ، فإن جميع مراكز بيانات Google مجهزة بنفس الأجهزة 1. لتجنب الخلط بين أجهزة الخادم وبرامج الخادم ، نستخدم في هذا الكتاب المصطلحات التالية:
- آلة (كمبيوتر) - وحدة من المعدات (أو ربما آلة افتراضية) ؛
- الخادم - وحدة برمجية تنفذ خدمة.
يمكن تشغيل أي خادم على الأجهزة ، لذلك لا نخصص أجهزة كمبيوتر معينة لبرامج خادم معينة. على سبيل المثال ، ليس لدينا جهاز معين يعمل عليه خادم البريد. بدلاً من ذلك ، يتم تخصيص الموارد من خلال نظام إدارة مجموعة Borg.
نحن نتفهم أن مثل هذا الاستخدام لمصطلح "الخادم" غير قياسي. من المعتاد أكثر تحديد مفهومين في وقت واحد: برنامج يخدم اتصالات الشبكة ، وفي نفس الوقت جهاز يقوم بتشغيل مثل هذه البرامج ، ولكن عندما نتحدث عن قوة الحوسبة في Google ، يكون الفرق بينهما كبيرًا. بمجرد التعود على تفسيرنا لكلمة "خادم" ، سيصبح من الواضح لك سبب أهمية استخدام مثل هذه المصطلحات المتخصصة ليس فقط في Google مباشرة ، ولكن في جميع أنحاء هذا الكتاب.
في الشكل. 2.1 أظهر تكوين مركز بيانات Google.
- يتم وضع عشرات السيارات على الرفوف.
- رفوف تقف في صفوف.
- يتكون صف واحد أو أكثر من مجموعة.
- عادة في بناء مركز البيانات (DPC) ، أو مركز البيانات ، توجد عدة مجموعات.
- تشكل العديد من مباني مراكز البيانات القريبة من بعضها البعض الحرم الجامعي.
داخل كل مركز بيانات ، يجب أن تكون جميع الأجهزة قادرة على الاتصال بفاعلية مع بعضها البعض ، لذلك أنشأنا مفتاحًا افتراضيًا سريعًا (مفتاح) بعشرات الآلاف من المنافذ. كان ذلك ممكنًا من خلال ربط مئات المفاتيح التي طورتها Google في "مصنع" قائم على هيكل شبكة Clos [Clos، 1953] ، والمُسمى Jupiter [Singh et al.، 2015]. في أقصى تكوين لها ، يدعم المشتري إنتاجية 1.3 Pb / s بين الخوادم.
ترتبط مراكز البيانات ببعضها البعض باستخدام شبكة العمود الفقري العالمية B4 [Jain et al.، 2013]. يحتوي B4 على بنية شبكة قابلة للتكوين من البرامج ويستخدم بروتوكول الاتصال المفتوح OpenFlow. يوفر B4 عرض نطاق ترددي عريض لعدد محدود من الأنظمة ويستخدم التحكم المرن في عرض القناة لزيادة متوسط قيمته إلى أقصى حد [كومار وآخرون ، 2015].
برمجيات النظام التي "تنظم" المعدات
يجب أن تكون البرامج التي توفر إدارة وتنظيم معداتنا قادرة على التعامل مع أنظمة ضخمة. أعطال الأجهزة هي واحدة من المشاكل الرئيسية التي تم حلها بمساعدة البرنامج. نظرًا للعدد الكبير من مكونات الأجهزة في الكتلة ، تحدث في كثير من الأحيان. في كل عنقود ، عادة ما تفشل آلاف الأجهزة في السنة وتفشل الآلاف من محركات الأقراص الثابتة. إذا قمت بضرب هذا الرقم في عدد المجموعات العاملة حول العالم ، فإن النتيجة مذهلة. لذلك ، نريد عزل المستخدمين عن مثل هذه المشاكل ، ولا تريد الفرق المشاركة في خدماتنا أن تشتت انتباههم بسبب مشكلات الأجهزة. يحتوي كل حرم مركز بيانات على فرق مسؤولة عن دعم المعدات والبنية التحتية لمركز البيانات.
إدارة الجهاز
Borg (الشكل 2.2) هو نظام إدارة عنقودية موزع [Verma et al.، 2015] ، يشبه Apache Mesos. يدير Borg وظائف على مستوى الكتلة.
بورغ مسؤول عن إطلاق وظائف المستخدم. يمكن أن تكون هذه المهام قيد التشغيل المستمر للخدمات أو العمليات المجمعة مثل MapReduce [Dean and Ghemawat، 2004]. يمكن أن تتكون من عدة (أحيانًا الآلاف) من المهام (المهام) المتطابقة - لأسباب تتعلق بالموثوقية ، ولأن عملية واحدة ، كقاعدة عامة ، غير قادرة على معالجة كل حركة مرور الكتلة. عندما يبدأ بورغ المهمة ، يجد الأجهزة لأداء مهامه ويأمرها ببدء برنامج الخادم. ثم يراقب بورغ حالة هذه المهام. إذا لم تعمل المهمة بشكل صحيح ، يتم إتلافها وإعادة تشغيلها ، ربما على جهاز آخر.
نظرًا لتوزيع المهام بحرية بين الأجهزة ، فلا يمكننا استخدام عناوين IP وأرقام المنافذ للوصول إليها. يتم حل هذه المشكلة عن طريق مستوى إضافي من التجريد: عند بدء مهمة ، يخصص Borg اسمًا للمهمة ورقمًا (فهرس) لكل مهمة باستخدام خدمة تسمية Borg (BNS). بدلاً من استخدام عنوان IP ورقم المنفذ ، ترتبط العمليات الأخرى بمهام Borg باسم BNS ، والتي تحول بعد ذلك BNS إلى عنوان IP ورقم المنفذ. على سبيل المثال ، يمكن أن يكون مسار BNS عبارة عن سلسلة مثل / bns / <cluster> / <user> / <task_name> / <task_number> ، والتي يتم ترجمتها بعد ذلك (من المعتاد قول "مسموح به" على الشبكات) بالتنسيق <عنوان IP>: <port> .
بورغ مسؤول أيضا عن تخصيص الموارد للمهام. يجب أن تشير كل مهمة إلى الموارد المطلوبة لإكمالها (على سبيل المثال ، ثلاثة نوى للمعالج و 2 غيغابايت من ذاكرة الوصول العشوائي). باستخدام قائمة المتطلبات لجميع المهام ، يمكن لـ Borg توزيع المهام بين الأجهزة على النحو الأمثل ، مع الأخذ في الاعتبار اعتبارات تحمل الخطأ أيضًا (على سبيل المثال ، لن يبدأ Borg جميع مهام مهمة واحدة على نفس الحامل ، لأن تبديل هذا الحامل سيكون نقطة حرجة في حالة الفشل) المهام).
إذا حاولت مهمة الحصول على موارد أكثر مما هو مطلوب ، فإن بورغ يدمرها ثم يعيد تشغيلها (نظرًا لأنه يفضل عادةً أن تكون هناك مهمة تتعطل في بعض الأحيان وتعيد تشغيلها لا تتم إعادة تشغيلها على الإطلاق).
التخزين
للوصول السريع إلى البيانات ، يمكن للمهام استخدام القرص المحلي من الأجهزة ، ولكن لدينا العديد من الخيارات لتنظيم التخزين المستمر في المجموعة (وحتى البيانات المخزنة محليًا سيتم نقلها في النهاية إلى تخزين الكتلة). يمكن مقارنتها مع Luster ونظام الملفات الموزعة Hadoop (HDFS) - أنظمة الملفات المجمعة مع تطبيق مفتوح المصدر.
يوفر التخزين للمستخدمين القدرة على الوصول بسهولة وموثوقية إلى البيانات المتاحة للمجموعة. كما هو مبين في الشكل. 2.3 ، يحتوي المستودع على عدة طبقات.
1. تسمى الطبقة الدنيا D (من القرص ، على الرغم من أن المستوى D يستخدم كلاً من محركات الأقراص الثابتة التقليدية ومحركات الأقراص المحمولة). D هو خادم ملفات يعمل فعليًا على كافة أجهزة المجموعة. ومع ذلك ، فإن المستخدمين الذين يرغبون في الوصول إلى بياناتهم لا يريدون تذكر الجهاز الذي يتم تخزينهم عليه ، لذا فإن الطبقة التالية متصلة هنا.
2. فوق الطبقة D هي طبقة Colossus ، التي تنشئ نظام ملفات في المجموعة يوفر الدلالات المعتادة لنظام الملفات ، بالإضافة إلى النسخ والتشفير. Colossus هو خليفة GFS ، نظام ملفات Google (Ghemawat et al. ، 2003).
3. بعد ذلك ، هناك العديد من الخدمات الشبيهة بقاعدة البيانات التي تم إنشاؤها فوق مستوى العملاق.
- Bigtable [Chang et al.، 2006] هو نظام قاعدة بيانات غير علائقي (NoSQL) قادر على العمل مع قواعد بيانات بحجم بيتابايت. Bigtable عبارة عن قاعدة بيانات متفرقة وموزعة على الأخطاء ومتعددة الأبعاد ومرتبة يتم فهرستها حسب الصفوف والأعمدة ومفاتيح الطابع الزمني ؛ كل قيمة قاعدة بيانات هي مجموعة عشوائية من البايت غير مترجم. كما يدعم Bigtable النسخ المتماثل بين مراكز البيانات.
- يقدم Spanner [Corbett وآخرون ، 2012] واجهة تشبه SQL للمستخدمين الذين يحتاجون إلى تكامل البيانات واتساقها عند الوصول من أي مكان في العالم.
- تتوفر العديد من أنظمة قواعد البيانات الأخرى ، مثل Blobstore. لديهم كل نقاط القوة والضعف الخاصة بهم (انظر الفصل 26).
شبكة
تتم إدارة شبكات Google بعدة طرق. كما ذكرنا سابقًا ، فإننا نستخدم شبكة قابلة للتكوين بالبرنامج استنادًا إلى OpenFlow. بدلاً من أجهزة التوجيه الذكية ، لا نستخدم مفاتيح سخيفة ليست باهظة الثمن مع وحدة تحكم مركزية (مكررة) ، والتي تحسب مسبقًا أفضل مسار على الشبكة. هذا يسمح لك باستخدام معدات تحويل أبسط ، وتحريره من البحث عن المسار الذي يستغرق وقتًا طويلاً.
يجب تخصيص عرض النطاق الترددي للشبكة بشكل صحيح. نظرًا لأن Borg يحد من موارد الحوسبة التي يمكن أن تستخدمها المهمة ، فإن إدارة Bandwidth Enforcer (BwE) تدير النطاق الترددي المتاح لزيادة متوسط الإنتاجية. لا يرتبط تحسين عرض النطاق الترددي بالتكلفة فحسب: تحل إدارة حركة المرور المركزية عددًا من المشكلات التي يصعب حلها للغاية من خلال الجمع بين التوجيه الموزع وإدارة حركة المرور التقليدية (كومار ، 2015).
بعض الخدمات لديها وظائف تعمل على عدة مجموعات تقع في أجزاء مختلفة من العالم. من أجل تقليل وقت التأخير للأنظمة الموزعة عالميًا ، نود توجيه المستخدمين إلى أقرب مركز بيانات لديه السعة المناسبة لذلك. يقوم موازن تحميل البرامج العالمي (GSLB) بإجراء موازنة التحميل على ثلاثة مستويات:
- موازنة الحمل الجغرافي لاستعلامات DNS (على سبيل المثال ، www.google.com ) ، تم وصفه في الفصل 19 ؛
- موازنة التحميل على مستوى خدمات المستخدم (على سبيل المثال ، YouTube أو خرائط Google) ؛
- موازنة الحمل على مستوى استدعاء الإجراء البعيد (RPC) ، الموصوف في الفصل 20.
يحدد مالكو الخدمة أسماء رمزية لهم ، وقائمة بعناوين BNS للخادم والأداء المتوفر في كل موقع (يتم قياسه عادةً في استعلامات في الثانية - استعلامات في الثانية ، QPS). وبالتالي ، يقوم GSLB بتوجيه حركة المرور إلى عناوين BNS المحددة.
برامج النظام الأخرى
هناك مكونات أخرى مهمة لبرنامج مركز البيانات.
خدمة القفلتوفر خدمة Chubby Lock [Burrows، 2006] واجهة برمجة تطبيقات مشابهة لنظام الملفات لخدمة الأقفال. يعالج السمين الأقفال في جميع مراكز البيانات. ويستخدم بروتوكول Paxos للوصول بشكل غير متزامن إلى الإجماع (انظر الفصل 23).
يلعب السمين أيضًا دورًا مهمًا في اختيار المعالج. إذا تم توفير خمس نسخ طبق الأصل لمهمة لبعض الخدمات بغرض زيادة الموثوقية ، ولكن في لحظة معينة يقوم واحد منهم فقط بالعمل الحقيقي ، ثم يتم استخدام Chubby لتحديد هذه النسخة المتماثلة.
Chubby رائع للبيانات التي تتطلب موثوقية التخزين. لهذا السبب ، يستخدم BNS Chubby لتخزين نسبة مسارات BNS إلى عنوان IP: أزواج المنافذ.
المراقبة والإنذارنريد أن نتأكد من أن جميع الخدمات تعمل بشكل صحيح. لذلك ، فإننا نطلق العديد من الأمثلة على برنامج مراقبة Borgmon (انظر الفصل 10). يتلقى Borgmon بانتظام قيمًا قياسية من الخدمات المراقبة. يمكن استخدام هذه البيانات على الفور للإخطار أو تخزينها للمعالجة والتحليل اللاحقين ، على سبيل المثال ، لإنشاء الرسوم البيانية. يمكن استخدام هذا الرصد لأغراض مثل:
- إنشاء تنبيهات للمشاكل العاجلة ؛
- مقارنة السلوك: هل أدى تحديث البرنامج إلى تسريع الخادم ؛
- تقييم طبيعة التغيرات في استهلاك الموارد بمرور الوقت ، وهو أمر ضروري لتخطيط القدرات.
البنية التحتية لبرامجنا
تم تصميم بنية برنامجنا بحيث يمكن استخدام موارد أجهزة النظام بكفاءة أكبر. كودنا بأكمله متعدد الخيوط ، لذلك يمكن لمهمة واحدة استخدام العديد من النوى بسهولة. من أجل دعم لوحات المعلومات والمراقبة والتصحيح ، يتضمن كل خادم تطبيق خادم HTTP كواجهة يتم من خلالها توفير معلومات وإحصاءات تشخيصية لمهمة معينة.
"تتواصل" جميع خدمات Google باستخدام البنية التحتية لاستدعاء الإجراء البعيد (RPC) المسماة Stubby. هناك نسخة مفتوحة المصدر منه ، تسمى gRPC (انظر
grpc.io ). في كثير من الأحيان ، يتم إجراء استدعاء RPC حتى للروتين في البرنامج المحلي. هذا يسمح لك بإعادة توجيه البرنامج إلى مكالمات خادم آخر لتحقيق قدر أكبر من الوحدات النمطية أو مع نمو رمز الخادم الأصلي. يمكن لـ GSLB تنفيذ موازنة تحميل RPC بنفس الطريقة التي تتم بها واجهات الخدمة الخارجية.
يتلقى الخادم طلبات RPC من الواجهة الأمامية ويرسل RPC إلى الواجهة الخلفية. باستخدام المصطلحات التقليدية ، تسمى الواجهة الأمامية العميل ، وتسمى الواجهة الخلفية الخادم.
يتم نقل البيانات من وإلى RPC باستخدام بروتوكول التسلسل - ما يسمى مخازن البروتوكول المؤقت ، أو باختصار ، protobufs. هذا البروتوكول مشابه لـ Apache's Thrift ولديه العديد من المزايا على XML عندما يتعلق الأمر بتسلسل البيانات المنظمة: فهو أبسط ، وثلاث إلى عشر مرات أكثر ضغطًا ، و 20 إلى 100 مرة أسرع وأكثر تميزًا.
بيئتنا التنموية
تعد سرعة تطوير المنتج مهمة جدًا بالنسبة إلى Google ، لذلك أنشأنا بيئة خاصة تحقق أقصى استفادة من بنيتنا التحتية [Morgenthaler et al.، 2012].
باستثناء بعض المجموعات التي تكون منتجاتها مفتوحة المصدر ، وبالتالي تستخدم مستودعاتها المستقلة الخاصة بها (على سبيل المثال ، Android و Chrome) ، يعمل مهندسو برامج Google في مستودع واحد مشترك [Potvin، Levenberg، 2016]. هذا النهج له العديد من التطبيقات العملية التي تعتبر مهمة لعملية الإنتاج لدينا.
- إذا واجه المهندس مشكلة في مكون خارج مشروعه ، يمكنه إصلاح المشكلة ، وإرسال التغييرات المقترحة ("قائمة التغيير" - قائمة التغيير ، CL) إلى المالك للنظر فيها ، ثم تنفيذ التغييرات التي تم إجراؤها في الفرع الرئيسي للبرنامج.
- تتطلب التغييرات التي تطرأ على شفرة المصدر في المشروع الخاص بالمهندس النظر - إجراء مراجعة (مراجعة). جميع البرامج تمر بهذه المرحلة قبل اعتمادها.
عندما يتم تجميع البرنامج ، يتم إرسال طلب التجميع إلى خوادم مركز البيانات المتخصصة. حتى بناء المشاريع الكبيرة سريع لأنه يمكنك استخدام خوادم متعددة للترجمة المتوازية. كما تستخدم هذه البنية التحتية للاختبار المستمر. في كل مرة تظهر قائمة تغيير جديدة (CL) ، يتم تشغيل الاختبارات لجميع البرامج التي يمكن أن تتأثر بشكل مباشر أو غير مباشر بهذه التغييرات. إذا اكتشف الإطار أن التغييرات تعطل تشغيل أجزاء أخرى من النظام ، فإنه يخطر مالك هذه التغييرات. تستخدم بعض المشاريع نظام الضغط الأخضر ("الإرسال بنجاح") ، والذي بموجبه يتم إرسال الإصدار الجديد تلقائيًا إلى التشغيل التجاري بعد اجتياز الاختبارات.
شكسبير: مثال الخدمة
لتوضيح كيفية قيام Google بتطوير خدمة في بيئة صناعية ، ضع في اعتبارك مثالاً على خدمة افتراضية تتفاعل مع تقنيات Google. لنفترض أننا نريد تقديم خدمة تسمح لك بتحديد أي أعمال شكسبير تحدث الكلمة التي ذكرتها.
يمكننا تقسيم النظام إلى قسمين.
- مكون معالجة مجموعة يقرأ جميع نصوص شكسبير ، ينشئ فهرسًا ويكتبه إلى Bigtable. يتم تنفيذ هذه المهمة (بشكل أدق ، المهمة) مرة واحدة ، وربما في بعض الأحيان (بعد كل شيء ، قد يظهر بعض نص شكسبير الجديد!).
- تطبيق أمامي يقوم بمعالجة طلبات المستخدم النهائي. يتم تشغيل هذه المهمة دائمًا ، لأنه في أي وقت ، قد يرغب مستخدم من أي منطقة زمنية في البحث من خلال كتب شكسبير.
سيكون مكون معالجة الدفعة هو خدمة MapReduce ، التي ينقسم عملها إلى ثلاث مراحل.
1. في مرحلة رسم الخرائط ، تتم قراءة نصوص شكسبير وتقسيمها إلى كلمات منفصلة. سيتم إكمال هذا الجزء من العمل بشكل أسرع إذا تم إطلاق العديد من عمليات العمل (المهام) بالتوازي.
2. في مرحلة الترتيب العشوائي ، يتم فرز الإدخالات حسب الكلمة.
3. في مرحلة التخفيض ، يتم إنشاء مجموعات من النموذج (كلمة ، قائمة_منتجات).
كل مجموعة مكتوبة كسلسلة في Bigtable ، المفتاح هو الكلمة.
طلب دورة الحياة
في الشكل. 2.4 يوضح كيفية تقديم طلب المستخدم. أولاً ، ينقر المستخدم على رابط shakespeare.google.com في المتصفح. للحصول على عنوان IP المناسب ، يترجم جهاز المستخدم ("يحل") العنوان باستخدام خادم DNS (1). ينتهي استعلام DNS في نهاية المطاف على خادم Google DNS ، الذي يتفاعل مع GSLB. لتتبع تحميل حركة المرور لجميع خوادم الواجهة الأمامية حسب المنطقة ، تختار GSLB عنوان IP للخادم الذي سيتم إرجاعه إلى المستخدم.
يتصل المتصفح بخادم HTTP على العنوان المحدد. هذا الخادم (يطلق عليه Google Frontend أو GFE) هو خادم وكيل "عكسي" يقع على الطرف الآخر من اتصال TCP للعميل (2). تبحث GFE عن الخدمة المطلوبة (على سبيل المثال ، يمكن أن تكون خدمة بحث أو خرائط أو - في حالتنا ، خدمة شكسبير). الوصول إلى GSLB بشكل متكرر ، يجد الخادم خادم شكسبير الأمامي المتوفر ويتصل به من خلال استدعاء إجراء بعيد (RPC) ، يحيل طلب HTTP المستلم من المستخدم (3).
يقوم خادم شكسبير بتحليل طلب HTTP وإنشاء "مخزن مؤقت للبروتوكول" (protobuf) يحتوي على الكلمات التي سيتم العثور عليها. الآن ، يجب على خادم الواجهة الأمامية لشكسبير الاتصال بخادم شكسبير الخلفي: يتصل الأول بـ GSLB للحصول على عنوان BNS لمثيل مناسب وغير محمل من المثال الثاني (4). بعد ذلك ، يتصل خادم الواجهة الخلفية لشكسبير بخادم Bigtable لتلقي البيانات المطلوبة (5).
يتم كتابة النتيجة على استجابة protobuf وإعادتها إلى خادم شكسبير الخلفي. تقوم الواجهة الخلفية بتمرير protobuf بنتيجة الخدمة إلى خادم شكسبير الأمامي ، الذي ينشئ مستند HTML ويعيده كرد على المستخدم.
هذه السلسلة الكاملة من الأحداث تجري في غمضة عين - في بضع مئات من المللي ثانية فقط! نظرًا لوجود العديد من المكونات ، فهناك العديد من الأماكن التي قد يحدث فيها خطأ محتمل ؛ على وجه الخصوص ، يمكن أن يؤدي الفشل في GSLB إلى تفكيك كل العمل ويؤدي إلى الانهيار. Google, , ( ), , . ,
www.google.com , .
أظهر اختبار الحمل أن خادم الواجهة الخلفية لدينا يمكنه معالجة حوالي 100 طلب في الثانية (QPS). أظهرت التجارب الميدانية مع عدد محدود من المستخدمين أن ذروة الحمل يمكن أن تصل إلى 3470 QPS تقريبًا ، لذلك نحتاج إلى إنشاء 35 مهمة على الأقل. ومع ذلك ، فإن الاعتبارات التالية تقول أننا بحاجة إلى 37 مهمة على الأقل ، أو N + 2.- أثناء التحديث ، ستكون إحدى المهام غير متاحة مؤقتًا ، لذلك ستظل 36 مهمة نشطة.
- أثناء الترقية ، قد يحدث فشل في الأجهزة ، مما ينتج عنه 35 مهمة متبقية فقط - تمامًا مثل العدد المطلوب لخدمة ذروة الحمل.
: 1430 QPS , 290 — , 1400 — 350 — . - , : , , . N + 2 , 17 , 16 — — . , , ( ), — N + 2 N + 1. : GSLB - , 20 % , . 2–3 .
- Bigtable, . - Bigtable, , , Bigtable . , Bigtable , . Bigtable , , .
, . , , .
»يمكن العثور على مزيد من المعلومات حول الكتاب على
موقع الناشر على الويب»
المحتويات»
مقتطفات20% —
Site Reliability Engineering