Когда большинство людей говорят о распределенных системах, они могут сделать определенные предположения о том, как система функционирует. Например, мы обычно можем (безопасно) предположить, что распределенная система - независимо от сложности ее настройки или архитектуры - может использоваться ее пользователями.
На первый взгляд это может показаться очень очевидным, но чем глубже мы углубляемся в распределенные системы, тем чаще мы сталкиваемся с ситуациями, когда наша система на самом деле непригодна для наших конечных пользователей. И это делает систему немного шаткой, ненадежной и ненадежной. Конечно, никто из нас этого не хочет - звучит плохо. Когда мы проектируем и строим систему, мы надеемся (и, возможно, молимся!), Что она работает и может, так сказать, стоять на своих двух ногах. В мире распределенных систем надежность системы и ее самодостаточность тесно связаны с тем, как она была построена, и с какими ситуациями она способна справиться.
Надежная система - это система, способная противостоять возникающим перед ней препятствиям, к чему мы все стремимся. Но за надежностью и архитектурой системы стоит целый язык, в который мы еще не углубились, и эти термины и концепции часто встречаются в этой области. Итак, давайте углубимся в то, что делает системы надежными и как о них говорить!
Готово, готово, доступно для использования
По сути, надежная распределенная система - это система, которая ведет себя определенным образом. В зависимости от типа системы, которую мы создаем, и того, что мы ожидаем от нее, «надежность» может быть определена по-разному (не говоря уже о том, что некоторые системы могут уделять больше внимания определенным аспектам надежности по сравнению с другими. ).
Но независимо от особенностей того, что наша система собирается делать или как она построена, одно можно сказать наверняка: мы хотим, чтобы наши пользователи имели к ней доступ! В мире вычислений, если система может быть доступна конечным пользователям (и ведет себя должным образом при обращении к ней), она считается доступной.
Чем чаще система ведет себя правильно с точки зрения пользователя, это определяет ее доступность. Часто это может быть так же просто, как возможность пользователю получить доступ к системе или возможность извлекать некоторые данные и взаимодействовать с ними; в конечном итоге доступность системы полностью зависит от того, что именно она делает. Но в качестве базового уровня мы можем предположить, что пользователь должен иметь возможность взаимодействовать с системой на фундаментальном уровне - например, он должен иметь доступ к своей учетной записи, веб-странице или приложению. - для того, чтобы система считалась «доступной».
Теперь, как разработчикам и создателям системы, для нас имеет смысл серьезно учитывать доступность при построении и обслуживании распределенной системы. Ясно, что мы хотели бы, чтобы наши пользователи имели доступ к нашей системе, и, скорее всего, мы были бы первыми, кто узнал бы, если наши (возможно, рассерженные?) Пользователи не смогли получить доступ к системе, как они ожидали .
К счастью, есть показатель, с которым мы, возможно, уже сталкивались, который помогает нам оценить и количественно оценить, насколько хорошо мы справляемся, когда дело доходит до удовлетворения ожиданий и потребностей наших конечных пользователей! Время безотказной работы - это способ измерить доступность нашей системы.
Мы можем рассчитать время безотказной работы системы на основе процента от общего времени в году, в течение которого система была доступна для своих пользователей. Например, если время безотказной работы системы составляло 99% - также иногда называемое «две девятки» - в течение года, мы можем сделать вывод, что она была недоступна для 1% в году, что эквивалентно 3,65 дням (мы знаем это, потому что 365, умноженное на 0,01, равняется 3,65 дням). В этом примере поддающийся количественной оценке 1% года, в течение которого система была недоступна для доступа пользователей, называется простоем или противоположность времени безотказной работы.
Простои - неизбежная часть распределенных систем, хотя мы, конечно, хотим этого избежать! Важной частью попыток избежать простоев для наших пользователей является понимание того, что его вызывает, а затем планирование решения этого вопроса. Итак, давайте подробнее рассмотрим, какие факторы стоят на нашем пути, когда дело касается доступности!
Сопротивление и терпение к ошибкам
Когда дело доходит до создания доступных распределенных систем, мы все стремимся к созданию доступных систем, которые всегда работают и доступны для наших пользователей. Но полной доступности добиться сложно, в основном из-за некоторых раздражающих, но постоянно присутствующих факторов.
Во-первых, иногда вещи, которые мешают нам обеспечить 100% безотказную работу и полную доступность, являются ... нашими собственными творениями! В частности, мы можем отключить часть нашей системы, чтобы обеспечить некоторое обслуживание. Когда мы сами выполняем обслуживание, мы почти всегда контролируем, когда часть нашей системы должна стать недоступной, что также известно как плановое обслуживание.
Однако по мере того, как Интернет (и его инструменты!) Становятся все более и более распределенными, многие системы фактически полагаются на другие системы для некоторой части своих услуг; когда сторонние службы и внешние службы отключаются для обслуживания, мы можем не иметь права голоса по этому поводу (что делает это внеплановое обслуживание), но это, безусловно, повлияет на время безотказной работы. . Но техническое обслуживание - это даже не самый страшный фактор, стоящий на нашем пути, поскольку в большинстве ситуаций мы заранее знаем о техническом обслуживании и потенциальных простоях (и, возможно, именно мы несем за это ответственность!).
Вместо этого я бы сказал, что больше пугают сбои сети или сбои в более крупной сети распределенной системы. Когда что-то идет не так в сети, мы, к сожалению, мало что контролируем и не замечаем! Часто это может быть проблема с оборудованием, которую мы даже не в состоянии исправить. Например, если что-то в центре обработки данных, в котором находится сервер, на котором выполняется процесс, от которого мы зависим, теряет электричество ... ну, мы не так много можем сделать, чтобы предотвратить это. .
Еще один каскадный фактор, связанный с перебоями в работе сети, заключается в том, что даже когда сбой происходит и (в конечном итоге) устраняется само, может пройти некоторое время после сбоя, в котором система все еще перезапускается и, следовательно, снова не полностью доступен. Например, если процесс убит или завершен из-за сбоя сети, ему может потребоваться перезагрузка или перезагрузка каким-либо образом, когда сеть в конечном итоге вернется - и это дополнительное время, которое также в конечном итоге влияют на время простоя!
Очевидно, что существует множество факторов, которые могут увеличить время простоя и помешать нам достичь высокой доступности. Конечно, с точки зрения программного обеспечения внутри системы может возникнуть сбой. Но что-то может пойти не так и с точки зрения оборудования!
Так что мы можем сделать? Что ж, именно здесь отказоустойчивые системы начинают звучать действительно хорошо. Отказоустойчивая система - это система, которая способна обрабатывать и учитывать сбои внутри нашей системы; даже когда происходит сбой оборудования, и что-то перестает работать, система может продолжать функционировать должным образом! Для целей этой статьи давайте подумаем о сбоях как о сбоях, связанных с оборудованием (далее в этой серии мы поговорим о различных типах сбоев и сбоев, в том числе о сбоях и сбоях). связанных с программным обеспечением).
Если мы остановимся и серьезно подумаем об этом, мы сможем понять, что это устраняет два основных фактора, которые мешали нам достичь полной доступности раньше: отсутствие перебоев в работе оборудования (сети) и отсутствие времени, затрачиваемого на их восстановление. Другими словами, никаких простоев из-за сбоев оборудования!
Если это звучит слишком хорошо, чтобы быть правдой ... ну, это потому, что иногда это действительно так.
Обеспечение доступного и терпимого баланса
Трудно добиться отказоустойчивости, и обычно это требует больших затрат. На самом деле существуют некоторые современные сервисы, которые предоставляют полностью отказоустойчивое оборудование. Однако внутренняя механика этого может быть довольно сложной и обычно включает в себя обнаружение, когда какая-то часть оборудования выходит из строя, и немедленное создание резервной / заменяющей части оборудования, которая уже установлена и готова перейти на место вышедшей из строя части, когда это действительно терпит неудачу. Если для вас это звучит утомительно, не волнуйтесь - мне тоже нужно много сделать!
По правде говоря, создание отказоустойчивой системы, которая всегда доступна и имеет нулевое время простоя, может быть не только дорогостоящим в реализации, но и иногда не стоит того. Время простоя само по себе не обязательно должно быть плохим, особенно если время простоя минимально по сравнению с временем безотказной работы.
Вместо того, чтобы пытаться быть полностью доступными, мы можем попытаться создать в основном доступную систему, которую часто называют высокодоступной системой . Мы можем стремиться минимизировать время простоя в максимально возможной степени, не изнуряя себя до точки внедрения системы, которая гарантирует нам нулевое время простоя. Большинству систем на самом деле не требуется «нулевое» время простоя, особенно если время простоя довольно невелико, а выгода от внедрения отказоустойчивой системы не стоит затрат только на наличие высокодоступной системы.
Когда дело доходит до разработки высокодоступной системы с минимальным временем простоя, краеугольным камнем, который держит все это вместе, является способ, которым наша система восстанавливается после сбоев. Когда мы проектируем систему, мы можем стремиться к тому, чтобы она была максимально отказоустойчивой; если мы знаем, что что-то может выйти из строя, мы можем спланировать, что произойдет в нашей системе, если это что-то произойдет.
Это может означать наличие плана для одной части системы, которая должна вмешаться, если другая часть выйдет из строя, или учет того, как отказавшая часть исправит себя и снова присоединится к остальной системе. Если мы проектируем отказоустойчивую систему, мы минимизируем возможное время простоя и, будем надеяться, получим систему с высокой доступностью.
Конечно, здесь следует упомянуть одно предостережение: мы можем планировать восстановление только после тех неисправностей, о которых мы знаем в нашей системе. Если мы не знаем, что что-то может выйти из строя, то, конечно, мы не можем найти способ исправить это. Неизвестные сбои - и впоследствии неучтенные случаи восстановления - могут добавить к нашим потенциальным факторам, способствующим простоям.
Но послушайте, небольшое несовершенство - это нормально! Мы (со временем) найдем способ избавиться от этого. 😉
Ресурсы
Поскольку концепции доступности и отказоустойчивости являются фундаментальными для распределенных систем, эти термины часто встречаются в академических статьях, а также во вводных материалах. К счастью, это просто означает, что у нас есть обширные знания по этой теме! Ниже приведены несколько отличных исходных мест, с которых можно начать, если вы ищете дополнительные ресурсы, чтобы продолжить чтение.
- Введение в распределенные системы, Google
- Подробное знакомство с распределенными системами, Станислав Козловский
- Распределенные системы: отказоустойчивость, профессор Юсси Кангашарью
- Распределенные системы для развлечения и прибыли, Микито Такада
- Что такое высокая доступность?, Эрика Хайди
- Высокая доступность или отказоустойчивость, IBM
