В настоящее время у нас есть классическое n-уровневое приложение: DB / web service / front-end. У него есть другие компоненты, но это основной макет.

Мы хотим улучшить доступность приложения по 3 основным причинам:

1. Наш хост иногда испытывает перебои в работе (как и все они), и мы хотим минимизировать влияние на наших клиентов, например, они бы включили центр обработки данных B, если центр обработки данных A не работает.
2. Когда мы обновляем версию, мы закрываем сайт для обслуживания, и обычно это занимает несколько часов (сценарии миграции и т. Д.). Мы хотели бы, чтобы пользователи имели более плавный переход с минимальным временем простоя, насколько это возможно (они используют сервер B, пока обновляется сервер A).
3. Необязательно, наши клиенты находятся по всему миру, и мы хотим, чтобы они получали наилучшие впечатления, несмотря на их, возможно, дурацкие связи (любой, кто работал с индийскими разработчиками, должен знать, что я имею в виду). В идеале, мы хотели бы иметь возможность подключить сервер в их офисе (или использовать центр обработки данных рядом с их городом), и он бы легко интегрировался в нашу архитектуру.

Нам удаленно не нужна доступность 99%, даже 95%. Это приложение для управления документами. Никому нет дела. Но поскольку миграция может занять некоторое время, и во всем мире есть клиенты, иногда мы не позволяем клиенту работать большую часть дня.

Что касается SQL, то, хотя нет «правильных» администраторов баз данных, мы знаем о возможностях SQL : репликация, зеркалирование и т. Д. Со стороны БД найти ресурсы для этого довольно легко. Что труднее всего остального: хранение сессий, кода и т. Д. Если мой сервер веб-сервиса выходит из строя, как мой пользовательский интерфейс знает, что он должен переключаться? Как мои сеансы сохраняются на серверах?

К сожалению, никто из нас не имеет опыта в этой области, и мы даже не знаем, с чего начать. Есть ли лучшие практики для этого? Шаблоны проектирования? Библиотеки (которые должны быть бесплатными, потому что у нас нет денег)?

Мы используем ASP.Net и SQL Server с веб-сервисом WCF в середине. У нас есть куча служб Windows, но они не являются критически важными, и я предполагаю, что методы работы с веб-сайтом будут применимы к службам.

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

Вам необходимо уточнить, какой тип высокой доступности вы ищете. Есть высокодоступные приложения, которые я запускаю, которые должны работать до 95% времени. Есть другие, которые должны работать на 99%. Я могу думать о сценариях жизни или смерти, которые требуют 100% безотказной работы. Просто у этих троих принципиально разные подходы и затраты.

Просто предположите, основываясь на ваших потребностях и SLA на 95-99% времени безотказной работы:

• Миграция базы данных должна иметь место в реальном времени для большинства изменений. Практика Эволюционного проектирования баз данных . Для изменений, которые требуют более агрессивного поведения, у вас есть несколько вариантов. Один из них - принять время простоя. Если возможно, работа вашего сервиса в режиме только для чтения может работать. Для полной функциональности я давно хотел попробовать ScaleArc. Похоже, действительно удобный инструмент для масштабирования и отказоустойчивости в мире SQL Server.
• Размещение серверов на сайтах ваших клиентов - это рецепт неуправляемой катастрофы, если у вас нет стратегий развертывания мирового класса (которых у вас еще нет, исходя из описания ваших миграций). Не выдвигайте облачные сервисы сразу, потому что у вас проблемы с производительностью. Решайте проблемы с производительностью сейчас, и тогда вам не придется иметь дело с более дорогостоящими проблемами.
• Ваш сервер состояний должен быть какой-то базой данных. Следуйте их рекомендациям HA. Для этого вы можете использовать SQL Server, поскольку он у вас уже есть.
• Говоря о базах данных, репликация не включает HA. Фактически, SQL Replication будет вызывать головные боли на каждом шагу (если судить по сценариям репликации с несколькими узлами). Зеркалирование может работать, но последнее, что я помню, для кластеризации SQL требуется от 1 до 5 минут для переключения на новый сервер. Я слышал хорошие новости о AlwaysOn, но я все еще подозрительно, учитывая послужной список Microsoft. Что-то вроде ScaleArc может быть более полезным здесь.
• Ваш веб-сервер должен быть без сохранения состояния. Раскрутите три или четыре и поместите их за балансировщик нагрузки. Это решает ваши проблемы с работой. Как упоминал ранее Фредерик, вы также можете выполнять развертывание таким образом.
• Ваш веб-сервис, вероятно, не должен иметь состояния. Если нет, посмотрите, сможете ли вы разбить его на куски без сохранения состояния и состояния. Повторное размещение нескольких его экземпляров за одним и тем же балансировщиком нагрузки решает проблемы бесперебойной работы и позволяет использовать более интересные сценарии развертывания (например, развертывание сине-зеленого цвета).

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

Получение некоторого уровня высокой готовности на уровне веб-приложений и приложений:

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

2. Ваш веб-сайт и уровень приложений должны иметь независимый балансировщик нагрузки. NGINX справится с задачей, но IIS тоже может это сделать (ARR).

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

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

На стороне обновления:

1. Разработайте сценарии базы данных таким образом, чтобы обновления базы данных могли выполняться во время работы системы, другими словами, поддерживать обратную совместимость. Шаблон, который хорошо работает для этого: «развернуть, затем сжать» -> сделать только аддитивные, обратно совместимые изменения, но удаляя зависимости от полей (и т. Д.), От которых вы хотите избавиться; затем обновите все клиенты базы данных до последней версии; затем выполните другое обновление базы данных, чтобы избавиться от старых полей (и т. д.) в базе данных. Это может быть медленным процессом, если у вас большая база данных, и вы должны быть осторожны, чтобы не снизить производительность вашей системы.

2. Обновление уровня вашего приложения: поскольку вы не используете облачную среду, я рекомендую вам придерживаться стандартного шаблона развертывания: выполнить последовательное обновление веб-страниц и блоков среднего уровня. Если развертывание идет не так, выньте коробку из балансировщика нагрузки, как если бы вы потерпели неудачу.

Слово предупреждения: превращение системы, которая не была разработана для HA, в систему, которая может быть длительным и дорогостоящим процессом. Вам придется идти на компромиссы по пути (стоимость против усилий по достижению определенного уровня доступности)

Ваша облачная паранойя неоправданна - провайдеры, такие как AWS в сочетании с хорошей практикой с вашей стороны, могут контролировать / минимизировать большинство рисков - загляните на свою страницу соответствия, чтобы понять, с какими правилами они совместимы: https: // aws .amazon.com / соответствия /

TL; DR: сборка избыточная, модульная; проверка доступности; внимательно следить.

После осознания того, что попытка сжать любое объяснение может занять очень много времени, я запишу все сделанные мной наблюдения.

Ставить под сомнение предпосылку

Облачная система - это панацея

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

Мы не хотим использовать облачную систему, потому что x / y / z

Если вы не очень большая организация, вам лучше использовать облачные системы. В топ-3 облачных систем (AWS, MSFT, Google) работают тысячи инженеров, чтобы предоставить вам обещанные SLA и простую в управлении панель инструментов. На самом деле это хорошая сделка, чтобы использовать их вместо того, чтобы потратить ни копейки на этот дом.

Проблемы в определении объема и дизайне

Определение, количественная оценка, а затем постоянное измерение доступности службы является более сложной задачей, чем написание решения проблем доступности.

Определить и измерить «доступность» сложнее, чем ожидалось

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

Люди недооценивают сложности всегда доступной системы.

Чтобы обратиться к слону в комнате, позвольте мне сказать следующее: «Ни одна мультикомпьютерная система не доступна на 100%, возможно, в будущем, но не с использованием современных технологий». Здесь под современной технологией я имею в виду нашу неспособность посылать сигналы быстрее скорости света и тому подобное. Все заядлые инженеры-компаньоны знают о распределенных вычислительных ограничениях , и большинство из них не будут упоминать об этом на совещаниях, опасаясь, что они будут выглядеть как новички. Я скажу, что компенсировать всех тех, кто не упоминает ограничения распределенных вычислений , сложно, но не всегда доверяют компьютерам .

Люди переоценивают свои возможности инженера

К сожалению, доступность попадает в категорию, где вы не знаете, чего хотите, но знаете, чего не хотите. Немного сложнее, когда категория «знаю, чего хочет», например, пользовательский интерфейс. Это требует немного опыта и много чтения, чтобы учиться на опыте других и еще немного.

Создание доступной системы с нуля

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

Атрибуты системы, помогающие доступности

Следующие характеристики системы, как показали, способствовали доступности системы:

избыточность

Некоторые примеры этого: никогда не иметь только одну виртуальную машину за VIP или хранить только одну копию ваших данных. Это те вопросы, которые хороший IAAS облегчит для вас, но вам все равно придется принимать эти решения.

модульность

Модульный REST лучше, чем монолитная SOA. Даже модульный микросервис на самом деле более доступен, чем обычный HATEOS REST . Обоснование можно найти в обсуждении доходности в следующем разделе. Если вы выполняете пакетную обработку, то лучше выполнять пакетную обработку в разумных партиях за 10 с по сравнению с обработкой партии из 1 000 000.

упругость

"I am always angry"
                    - Hulk

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

Журнал тропа

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

Атрибуты доступности

Неисчерпывающий список атрибутов top-of-mind высшего уровня «доступности». Для обсуждения давайте предположим, что пользователь задает вопрос: «Сколько товаров у меня в корзине?».

правильность

Вы должны дать максимально точный ответ или все нормально делать ошибки? Просто для справки: когда вы снимаете деньги в банкомате, это не гарантирует правильности. Если банк обнаружит, что совершил ошибку, он может отменить транзакции. Если ваша система производит простые числа, то, я думаю, вы можете постоянно получать правильные ответы.

Уступать

Пропустите этот пункт, если вы ответили всегда - правильно для предыдущего вопроса темы. Иногда ответы на вопросы не должны быть точными, например, сколько у меня друзей на Facebook сейчас? Но ожидается, что ответ будет на уровне +/- 1 все время. Когда вы производите ожидаемый результат, ваша доходность составляет 100.

консистенция

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

Стоимость

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

На пути к улучшению доступности существующей системы

Оперативное управление отдельными машинами и сетью является настолько сложным, что я полагаю, что вы предоставили это облачному провайдеру или уже достаточно опытны, чтобы знать, что вы делаете. Я коснусь других тем при наличии. Для долгосрочной стратегии Define-Measure-Analyze-Control - это небесная пара, то, что я видел сам.

1. Определите, что является «доступностью» для ваших заинтересованных сторон
2. Как вы будете измерять то, что вы определили
3. Анализ первопричин для выявления узких мест
4. Задачи для улучшения
5. Непрерывный мониторинг ( контроль ) системы

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

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