Высокая доступность
Из Википедии, свободной энциклопедии
  (Перенаправлено из вычислений высокой доступности )
Перейти к навигации Перейти к поиску
"Always-on" перенаправляется сюда. Информацию об ограничении программного обеспечения см. В разделе Always-on DRM .

Высокая доступность ( HA ) - это характеристика системы, которая направлена ​​на обеспечение согласованного уровня эксплуатационных характеристик, обычно времени безотказной работы , в течение более длительного периода, чем обычно.

Модернизация привела к увеличению зависимости от этих систем. Например, больницам и центрам обработки данных требуется высокая доступность их систем для выполнения рутинных повседневных действий. Доступность относится к способности сообщества пользователей получить услугу или товар, получить доступ к системе, отправить ли новую работу, обновить или изменить существующую работу или собрать результаты предыдущей работы. Если пользователь не может получить доступ к системе, она - с точки зрения пользователя - недоступна . [1] Обычно термин простой используется для обозначения периодов, когда система недоступна.

Принципы

Есть три принципа проектирования систем в надежности техники , которые могут помочь достичь высокой доступности.

  1. Устранение единичных точек отказа . Это означает добавление или создание избыточности в системе, чтобы отказ компонента не означал отказ всей системы.
  2. Надежный кроссовер. В системах с резервированием точка кроссовера сама по себе становится единственной точкой отказа. Надежные системы должны обеспечивать надежный кроссовер.
  3. Обнаружение отказов по мере их возникновения. Если соблюдаются два вышеуказанных принципа, то пользователь может никогда не увидеть сбоя, но действия по техническому обслуживанию должны это сделать.

Запланированные и внеплановые простои

Можно различать плановые и внеплановые простои. Как правило, запланированный простой является результатом технического обслуживания , которое нарушает работу системы, и его невозможно избежать с установленной в настоящее время конструкцией системы. Запланированные события простоя могут включать исправления для системного программного обеспечения , требующие перезагрузки, или изменения конфигурации системы, которые вступают в силу только после перезагрузки. Как правило, запланированное время простоя обычно является результатом какого-либо логического события, инициированного руководством. Незапланированные простои обычно возникают из-за какого-либо физического события, такого как аппаратный или программный сбой или аномалия окружающей среды. Примеры незапланированных простоев включают перебои в подаче электроэнергии, отказ процессора илиКомпоненты ОЗУ (или, возможно, другие отказавшие аппаратные компоненты), отключение, связанное с перегревом, логически или физически разорванные сетевые соединения, нарушения безопасности или сбои различных приложений , промежуточного программного обеспечения и операционной системы .

Если пользователей можно предупредить о запланированных простоях, то это различие полезно. Но если требуется по-настоящему высокая доступность, то простои - это простои, независимо от того, запланированы они или нет.

Многие вычислительные сайты исключают запланированные простои из расчетов доступности, предполагая, что они мало или совсем не влияют на сообщество пользователей компьютеров. Поступая так, они могут утверждать, что обладают феноменально высокой доступностью, что может создать иллюзию непрерывной доступности . Системы, которые демонстрируют действительно постоянную доступность, сравнительно редки и стоят дороже, и в большинстве из них реализованы тщательно разработанные специальные решения, исключающие любую единую точку отказа и позволяющие онлайн-оборудование, сеть, операционную систему, промежуточное программное обеспечение, а также обновления, исправления и замены приложений. Для некоторых систем запланированное время простоя не имеет значения, например, простой системы в офисном здании после того, как все ушли домой на ночь.

Расчет в процентах

Доступность обычно выражается как процент времени безотказной работы за определенный год. В следующей таблице показано время простоя, которое будет допущено для определенного процента доступности, исходя из предположения, что система должна работать непрерывно. Соглашения об уровне обслуживания часто относятся к ежемесячному простою или доступности, чтобы рассчитать кредиты за обслуживание в соответствии с ежемесячными циклами выставления счетов. В следующей таблице показано преобразование заданного процента доступности в соответствующее количество времени, в течение которого система будет недоступна.

Доступность %Время простоя в год [примечание 1]Время простоя за кварталВремя простоя в месяцВремя простоя в неделюВремя простоя в сутки (24 часа)
90% («одна девятка»)36,53 дней9,13 дней73.05 часов16.80 часов2,40 часов
95% («полторы девятки»)18.26 дней4.56 дней36,53 часов8.40 часов1,20 часов
97%10.96 дней2,74 дня21.92 часов5,04 часов43.20 мин.
98%7.31 дней43,86 часов14,61 часов3,36 часов28,80 минут
99% («две девятки»)3.65 дней21,9 часов7.31 часов1,68 часов14,40 мин.
99,5% («две с половиной девятки»)1.83 дней10.98 часов3,65 часов50,40 минут7.20 минут
99,8%17,53 часов4.38 часов87,66 мин.20,16 мин.2,88 мин.
99,9% («три девятки»)8,77 часов2,19 часов43,83 мин.10.08 минут1,44 мин.
99,95% («три с половиной девятки»)4.38 часов65,7 мин.21,92 мин.5,04 мин.43.20 секунды
99,99% («четыре девятки»)52,60 минут13.15 минут4,38 мин.1.01 мин.8,64 секунды
99,995% ("четыре с половиной девятки")26.30 минут6.57 минут2,19 мин.30,24 секунды4,32 секунды
99,999% («пять девяток»)5.26 мин.1,31 мин.26.30 секунд6,05 секунды864.00 миллисекунд
99,9999% ("шесть девяток")31,56 секунды7,89 секунды2,63 секунды604,80 миллисекунд86,40 миллисекунды
99,99999% («семь девяток»)3,16 секунды0,79 секунды262,98 миллисекунды60,48 миллисекунд8,64 миллисекунды
99,999999% («восемь девяток»)315,58 миллисекунд78,89 миллисекунд26.30 миллисекунд6,05 миллисекунды864.00 микросекунд
99,9999999% («девять девяток»)31,56 миллисекунды7,89 миллисекунд2,63 миллисекунды604,80 микросекунд86,40 микросекунд

Время безотказной работы и доступность можно использовать как синонимы, если обсуждаемые элементы остаются согласованными. То есть система может работать, но ее услуги недоступны, как в случае сбоя сети . Это также можно рассматривать как систему, над которой можно работать, но ее услуги не улучшаются с функциональной точки зрения (в отличие от программных услуг / процессов). Здесь важна перспектива - является ли обсуждаемый элемент серверным оборудованием, серверной ОС, функциональной службой, программной службой / процессом и т. Д. Сохраняйте единство точки зрения на протяжении всего обсуждения, тогда время безотказной работы и доступность можно будет использовать как синонимы.

"Девятки"

Основная статья: Девять (чистота)

Проценты определенного порядка иногда называют числом девяток или «классом девяток» в цифрах. Например, электричество, которое доставляется без перебоев ( отключений , отключений или скачков напряжения ) в 99,999% случаев, будет иметь надежность 5 девяток или пятый класс. [2] В частности, этот термин используется в связи с мэйнфреймами [3] [4] или корпоративными вычислениями, часто как часть соглашения об уровне обслуживания .

Точно так же проценты, оканчивающиеся на 5, имеют общепринятые названия, традиционно это количество девяток, затем «пять», поэтому 99,95% - это «три девятки пять», сокращенно 3N5. [5] [6] Это обычно называют «три с половиной девятки», [7] но это неверно: 5 - это всего лишь 2, а 9 - 10, поэтому 5 - это 0,3 девятки (в следующей формуле: ): [примечание 2] 99,95% доступность 3,3 девятки, а не 3,5 девятки. [8] Проще говоря, переход от доступности 99,9% к доступности 99,95% - это коэффициент 2 (недоступность от 0,1% до 0,05%), а при переходе с 99,95% до 99,99% доступность - это коэффициент 5 (недоступность от 0,05% до 0,01%). ), более чем вдвое больше. [заметка 3]

Формулировка класса 9 на основе недоступности системы была бы

(см . Функции пола и потолка ).

Подобное измерение иногда используется для описания чистоты веществ.

В общем, число девяток не часто используется сетевым инженером при моделировании и измерении доступности, потому что его трудно применить в формуле. Чаще всего указывается недоступность, выражаемая как вероятность (например, 0,00001), или простои в год. Доступность, указанная как число девяток, часто встречается в маркетинговых документах. [ необходимая цитата ] Использование «девяток» было поставлено под сомнение, поскольку оно не отражает должным образом, что влияние недоступности зависит от времени его возникновения. [9]Для большого количества 9 с индекс «недоступности» (показатель времени простоя, а не времени безотказной работы) легче обрабатывать. Например, именно поэтому в показателях ошибок по битам жесткого диска или канала передачи данных используется показатель «недоступность», а не показатель доступности .

Иногда юмористический термин «девять пятерок» (55,5555555%) используется для контраста с «пятью девятками» (99,999%), [10] [11] [12], хотя это не настоящая цель, а скорее саркастическая ссылка на полностью неспособность достичь какой-либо разумной цели.

Измерение и интерпретация

Измерение доступности подлежит некоторой интерпретации. Систему, работавшую 365 дней в невисокосный год, мог затмить сбой сети, который длился 9 часов в период пиковой нагрузки; сообщество пользователей увидит систему как недоступную, а системный администратор потребует 100% времени безотказной работы.. Однако, учитывая истинное определение доступности, система будет доступна примерно на 99,9%, или три девятки (8751 час времени доступности из 8760 часов за невисокосный год). Кроме того, системы, испытывающие проблемы с производительностью, часто считаются частично или полностью недоступными для пользователей, даже если системы продолжают функционировать. Точно так же недоступность некоторых функций приложения может остаться незамеченной администраторами, но при этом иметь разрушительные последствия для пользователей - истинная мера доступности является целостной.

Доступность должна быть измерена для определения, в идеале с помощью комплексных инструментов мониторинга («инструментария»), которые сами по себе являются высокодоступными. При отсутствии инструментов, системы, поддерживающие обработку больших объемов транзакций в течение дня и ночи, такие как системы обработки кредитных карт или телефонные коммутаторы, часто по своей природе лучше контролируются, по крайней мере, самими пользователями, чем системы, которые испытывают периодические затишья. требование.

Альтернативный показатель - это средняя наработка на отказ (MTBF).

Тесно связанные концепции

Время восстановления (или расчетное время ремонта (ETR), также известное как целевое время восстановления (RTO)), тесно связано с доступностью, то есть общим временем, необходимым для планового отключения или временем, необходимым для полного восстановления после незапланированного простоя. Другой метрика - это среднее время восстановления (MTTR). Время восстановления может быть бесконечным при определенных конструкциях системы и сбоях, т. е. полное восстановление невозможно. Одним из таких примеров является пожар или наводнение, которое разрушает центр обработки данных и его системы при отсутствии вторичной аварии. центр восстановления данных.

Другая связанная концепция - это доступность данных , то есть степень, в которой базы данных и другие системы хранения информации достоверно регистрируют системные транзакции и сообщают о них. Управление информацией часто фокусируется отдельно на доступности данных или цели точки восстановления , чтобы определить допустимую (или фактическую) потерю данных с различными событиями сбоя. Некоторые пользователи могут терпеть перебои в обслуживании приложений, но не могут терпеть потерю данных.

Соглашение об уровне обслуживания ( «SLA») формализует цель доступности организации и требование.

Военные системы управления

Высокая доступность - одно из основных требований к системам управления в беспилотных транспортных средствах и автономных морских судах . Если система управления становится недоступной, наземная боевая машина (GCV) или противолодочный беспилотный корабль с непрерывным следом (ACTUV) будет потеряна.

Системный дизайн

Добавление большего количества компонентов в общий дизайн системы может подорвать усилия по достижению высокой доступности, поскольку сложные системы по своей природе имеют больше потенциальных точек отказа и их труднее реализовать правильно. В то время как некоторые аналитики выдвигают теорию о том, что наиболее высокодоступные системы придерживаются простой архитектуры (единой, высококачественной, многоцелевой физической системы с полным внутренним аппаратным резервированием), эта архитектура страдает от требования, что вся система должна быть сброшен для установки исправлений и обновлений операционной системы. Более сложные конструкции систем позволяют исправлять и обновлять системы без ущерба для доступности услуг (см. Балансировку нагрузки и переключение при отказе ).

Высокая доступность требует меньшего вмешательства человека для восстановления работы сложных систем; Причина в том, что наиболее частой причиной сбоев является человеческий фактор. [13]

Резервирование используется для создания систем с высоким уровнем доступности (например, бортовых компьютеров самолета). В этом случае требуется высокий уровень обнаруживаемости отказов и предотвращения отказов по общей причине. Два вида резервирования - это пассивное резервирование и активное резервирование.

Пассивное резервирование используется для достижения высокой доступности за счет включения в проект достаточной избыточной емкости для компенсации снижения производительности. Самый простой пример - это лодка с двумя отдельными двигателями, приводящими в движение два отдельных гребных винта. Судно продолжает движение к месту назначения, несмотря на отказ одного двигателя или гребного винта. Более сложный пример - несколько резервированных объектов производства электроэнергии в большой системе, включающей передачу электроэнергии . Неисправность отдельных компонентов не считается отказом, если результирующее снижение производительности не превышает пределы спецификации для всей системы.

Активное резервирование используется в сложных системах для достижения высокой доступности без снижения производительности. Несколько элементов одного и того же типа включены в проект, который включает метод обнаружения сбоя и автоматического перенастройки системы для обхода сбойных элементов с помощью схемы голосования. Это используется со сложными вычислительными системами, которые связаны между собой. Интернет- маршрутизация основана на ранних работах Бирмана и Джозефа в этой области. [14] Активное резервирование может ввести в систему более сложные режимы отказа, такие как непрерывная реконфигурация системы из-за неправильной логики голосования.

Конструкция системы с нулевым временем простоя означает, что моделирование и симуляция показывают, что среднее время наработки на отказ значительно превышает период времени между плановым обслуживанием , событиями обновления или сроком службы системы. Нулевое время простоя предполагает массивное резервирование, которое необходимо для некоторых типов самолетов и для большинства типов спутников связи . Система глобального позиционирования - это пример системы с нулевым временем простоя.

Инструментарий отказов может использоваться в системах с ограниченным резервированием для достижения высокой доступности. Действия по техническому обслуживанию выполняются в течение коротких периодов простоя только после срабатывания индикатора неисправности. Отказ является значительным только в том случае, если он происходит в критический период.

Моделирование и симуляция используются для оценки теоретической надежности больших систем. Результат такой модели используется для оценки различных вариантов дизайна. Создается модель всей системы, и модель подвергается нагрузке путем удаления компонентов. Моделирование избыточности включает критерий Nx. N представляет собой общее количество компонентов в системе. x - количество компонентов, используемых для напряжения системы. N-1 означает, что модель подвергается стрессу, оценивая производительность со всеми возможными комбинациями, когда один компонент неисправен. N-2 означает, что модель подвергается стрессу, оценивая производительность со всеми возможными комбинациями, когда два компонента неисправны одновременно.

Причины недоступности

Опрос, проведенный среди академических экспертов по доступности в 2010 году, выявил причины недоступности корпоративных ИТ-систем. Все причины относятся к несоблюдению передовой практики в каждой из следующих областей (в порядке важности): [15]

  1. Мониторинг соответствующих компонентов
  2. Требования и закупки
  3. Операции
  4. Предотвращение сетевых сбоев
  5. Избежание внутренних сбоев приложений
  6. Избегание сбоев внешних служб
  7. Физическая среда
  8. Резервирование сети
  9. Техническое решение резервного копирования
  10. Технологическое решение резервного копирования
  11. Физическое местонахождение
  12. Резервирование инфраструктуры
  13. Резервирование архитектуры хранилища

В 2003 г. была опубликована книга о самих факторах [16].

Издержки недоступности

Согласно отчету IBM Global Services за 1998 год , недоступные системы обошлись американским предприятиям в 4,54 миллиарда долларов в 1996 году из-за потери производительности и доходов. [17]

Смотрите также

  • Аварийное восстановление
  • Отказоустойчивость
  • Кластер высокой доступности
  • Общая эффективность оборудования
  • Надежность, доступность и удобство обслуживания (вычисления)
  • Техника надежности
  • Устойчивость (сеть)
  • Повсеместные вычисления

Примечания

  1. ^ Использование 365,25 дней в году. Для единообразия все время округлено до двух десятичных цифр.
  2. ^ См. Математические совпадения относительно основания 2 для получения подробной информации об этом приближении.
  3. ^ "В два раза больше" по логарифмической шкале, что означает два деления на 2:

использованная литература

  1. ^ Флойд Пьедад, Майкл Хокинс (2001). Высокая доступность: дизайн, методы и процессы . Прентис Холл. ISBN 9780130962881.
  2. ↑ Конспект лекций М. Нестеренко, Кентский государственный университет
  3. ^ Введение в новый мэйнфрейм: крупномасштабные коммерческие вычисления Глава 5 Доступность IBM (2006)
  4. ^ IBM zEnterprise EC12 Business Value Video на youtube.com
  5. ^ Драгоценные металлы, Том 4 . Pergamon Press. 1981. с. стр.262 . ISBN 9780080253695.
  6. ^ PVD для микроэлектроники: напыление для производства полупроводников . 1998. с. 387 .
  7. ^ Мерфи, Найл Ричард; Бейер, Бетси; Петофф, Дженнифер; Джонс, Крис (2016). Разработка надежности сайта: как Google управляет производственными системами . п. 38 .
  8. ↑ Джош Депрез (23 апреля 2016 г.). «Девятка из девяти» .
  9. ↑ Эван Л. Маркус, Миф о девятках
  10. ^ Ньюман, Дэвид; Снайдер, Джоэл; Тайер, Родни (24 июня 2012 г.). «Плачущий волк: Ложные тревоги скрывают атаки» . Сетевой мир . Vol. 19 нет. 25. с. 60 . Проверено 15 марта 2019 года . что приводит к сбоям и количеству времени безотказной работы ближе к девяти пятым, чем к пяти девяткам.
  11. ↑ Меткалф, Боб (2 апреля 2001 г.). «После 35 лет крестовых походов в области технологий Боб Меткалф уезжает в закат» . ITworld . Проверено 15 марта 2019 года . и пять девяток (а не девять пятерок) надежности
  12. ↑ Пилигрим, Джим (20 октября 2010 г.). «Прощай, пять девяток» . Clearfield, Inc . Проверено 15 марта 2019 года . но мне кажется, что по надежности сети мы приближаемся к 9-5 (55,5555555%), а не к 5-9
  13. ^ «Семь основных соображений по управлению конфигурацией для виртуальных и облачных инфраструктур» . Gartner . 27 октября 2010 . Проверено 13 октября 2013 года .[ мертвая ссылка ]
  14. ^ RFC 992 
  15. ^ Ульрик Франке, Понтус Джонсон, Йохан Кениг, Лив Маркс фон Вюртемберг: Доступность корпоративных ИТ-систем - байесовская модель на основе экспертов, Proc. Четвертый международный семинар по качеству и поддержке программного обеспечения (WSQM 2010), Мадрид, [1]
  16. ^ Маркус, Эван; Стерн, Хэл (2003). Чертежи для обеспечения высокой доступности (Второе изд.). Индианаполис, IN: John Wiley & Sons. ISBN 0-471-43026-9.
  17. ^ IBM Global Services, Повышение доступности систем , IBM Global Services, 1998, [2]

внешняя ссылка

  • Конспект лекций по корпоративным вычислениям в Тюбингенском университете
  • Конспект лекций профессора Фила Купмана по разработке встроенных систем
  • Калькулятор времени безотказной работы (SLA)
Источник « https://en.wikipedia.org/w/index.php?title=High_availability&oldid=1060360592 »
Contribute a better translation