Вопросы об одной точке отказа для небольших операций

1. Если вы не можете позволить себе или не нуждаетесь в кластере или запасном сервере, ожидающем подключения к сети в случае сбоя, кажется, что вы можете разделить службы, предоставляемые одним мощным сервером, на два менее мощных сервера. Таким образом, если сервер A выйдет из строя, клиенты могут потерять доступ, скажем, к электронной почте, а если сервер B выйдет из строя, они могут потерять доступ к системе ERP .

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

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

2. Часто рекомендуется использовать SAN, чтобы вы могли использовать кластеризацию или миграцию для поддержания работоспособности сервисов. Но как насчет самого SAN? Если бы я положил деньги на то, где произойдет сбой, это не будет происходить на базовом серверном оборудовании, он будет иметь какое-то отношение к хранилищу. Если у вас нет какой-либо избыточной SAN, то эти избыточные серверы не дадут мне уверенности. Лично для небольшой операции мне было бы разумнее инвестировать в серверы с избыточными компонентами и локальными дисками. Я вижу выгоду в более крупных операциях, где цена и гибкость SAN экономически выгодны. Но для небольших магазинов я не вижу аргумента, по крайней мере, для отказоустойчивости.

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

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

Край сети : у нас есть 2 интернет-соединения T1 и Comcast Business. Планируем перенести наш брандмауэр на пару старых компьютеров, работающих под управлением pfSense, используя CARP для HA.

Сеть : получение пары управляемых коммутаторов для ядра сети и использование связывания для разделения критически важных серверов между двумя коммутаторами предотвращает сбой коммутатора из-за всей шкалы данных.

Серверы : Все серверы имеют RAID и резервные источники питания.

Резервный сервер : у меня старая система, которая не такая мощная, как основной файловый сервер, но в raid5 есть несколько больших дисков sata, которые делают почасовые снимки основного файлового сервера. У меня есть сценарии, настроенные для этого, чтобы переключать роли в качестве основного файлового сервера, если он отключается.

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

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

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

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

Мы использовали Backup Exec System Recovery для некоторых критических систем. Не столько для ежедневного резервного копирования, сколько для восстановления. Мы можем восстановить на другое аппаратное обеспечение, если оно доступно, и мы также используем программное обеспечение для преобразования образа резервной копии в виртуальную машину. Если сервер выходит из строя и нам нужно дождаться ремонта оборудования, мы можем запустить виртуальную машину на другом сервере или рабочей станции и бездействовать. Не идеально, но он может быть запущен быстро.

Относительно SAN: почти все, что вы используете, будет излишним. Даже если это один корпус, внутри будут два блока питания, два разъема и две «головки», каждая из которых имеет связь со всеми дисками. Даже такие простые вещи, как MD3000, продаваемый Dell, обладают всеми этими функциями. Сети SAN разработаны для того, чтобы быть ядром ваших устройств, поэтому они созданы так, чтобы выдерживать практически любые случайные сбои оборудования.

При этом у вас есть точка зрения, что избыточность не всегда лучший вариант. ОСОБЕННО, если это увеличивает сложность. (и так будет) Лучше задать вопрос: «Сколько компания примет время простоя». Если потеря вашего почтового сервера в течение дня или двух не имеет большого значения, то вам, вероятно, не стоит беспокоиться о двух из них. Но если сбой в работе веб-сервера начинает каждую минуту терять реальные деньги, возможно, вам стоит потратить время на создание подходящего кластера для него.

Чем больше у вас серверов, тем больше шансов что-нибудь сломать, это один из способов посмотреть на это. Другой - если кто-то сломается, вы на 100% скрипите, также как вы говорите.

Наиболее распространенный аппаратный сбой - это HD, как вы сказали выше. Независимо от того, на сколько вы хотите разделить операции, вам необходимо использовать RAID-массив для хранения данных.

Я бы проголосовал за пару серверов (конечно, RAIDed) вместо одного массивного, как за стабильность работы, так и за производительность. Меньше программного обеспечения, сталкивающегося с каждым запросом ресурсов, уменьшенным беспорядком, большим количеством дисков для чтения / записи, и так далее.

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

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

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

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

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

Это поддерживается, например, Proxmox (но я думаю, что это также поддерживается XCP-ng / XenServer и, вероятно, ESXi).

Давайте рассмотрим установку 3 узлов. Все с RAID, резервным блоком питания, резервной сетью.

• Узлы A и B имеют мощный процессор и много оперативной памяти.
• Узел C является более скромным в ЦП / ОЗУ, но имеет много памяти и используется для обеспечения кворума для сторожевого таймера высокой доступности и резервного копирования хоста.

Тогда два варианта:

1. Все виртуальные машины обычно работают на узле A и реплицируются на узле B (требуются приличные проценты процессора)
2. Виртуальные машины разделены между узлами A и B и реплицированы взаимно, некоторые из узла A в узел B и из узла B в узел A.

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

Во втором варианте (виртуальная машина обычно разделяется между узлами A и B), вы должны определить, какой виртуальной машине разрешено возвращаться в оперативный режим. Поскольку загрузка вашей виртуальной машины обычно распределяется между двумя серверами, запуск всех из них на одном узле может привести к исчерпанию ОЗУ узла или перегружению ЦП.

«Хотя на первый взгляд кажется, что это будет более надежно, не увеличивает ли это вероятность отказа оборудования?»

• С аппаратной точки зрения я не вижу, как это практически увеличивает вероятность отказа. Здесь очень много переменных, и я никогда не изучал вероятность, но для упрощения: допустим, Dell делает 1 плохой сервер на каждые 100 000, которые они делают. Ваши шансы изменились с 1 на 100 000 до 2 на 100 000 (или 1 на 50 000). Так что да, шанс вдвое больше, но все же из-за масштаба шансы практически не отличаются.
• Я думаю, что здесь важна перспектива . «Вы настраиваете себя на удвоение количества неудач». Возможно, с вашей точки зрения, но в обоих предоставленных вами сценариях электронная почта работает на одном сервере, а ERP - на одном сервере. Таким образом, с точки зрения электронной почты или э.и.и.и (что заботит бизнес), это действительно то же самое. Если только они не становятся одинокими или не любят свое пространство ;-)
• Я думаю, что вы также должны смотреть на это с точки зрения людей. Я думаю, что сбой из-за ошибок людей, возможно, более вероятен, и таким образом кто-то, вероятно, испортит только один сервер за раз. Это также облегчает выявление проблем с такими вещами, как нагрузка. Если на сервере работают и электронная почта, и веб-сайт, уделите дополнительное время выяснению проблемы.

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

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

Мой подход по умолчанию - избегать какой-либо централизованной инфраструктуры. Например, это означает, что нет SAN , нет балансировки нагрузки . Вы также можете назвать такой централизованный подход "монолитным".

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

Пример электронной почты

Электронная почта странная, потому что это устаревшая система (которая работает). Если бы электронная почта была изобретена сегодня, она, вероятно, использовала бы API-интерфейсы RESTFul на веб-серверах, и данные были бы в базе данных, которая могла бы реплицироваться с использованием обычных инструментов (репликация транзакций, инкрементные резервные копии).

Решение программной архитектуры заключается в том, что веб-приложение будет подключаться к одному из списка доступных узлов (в произвольном порядке), а если оно недоступно, оно будет пытаться подключиться к другому узлу (в произвольном порядке). Клиент может быть выгнан с сервера, если он слишком занят. Здесь не требуется балансировщик нагрузки для подключения к веб-ферме; и нет необходимости в SAN для высокой доступности. Также возможно разделить базу данных на отдел или географию.

Товар означает ...

Таким образом, вместо дорогих 1 или 2 серверов и SAN с внутренними мерами избыточности, вы можете использовать несколько недорогих недорогих машин с низким энергопотреблением.

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

• Процент избыточности - если у вас есть 2 сервера, если один отказывает, у вас остается 1 (50%). Если у вас есть 10 обычных серверов и один из них не работает, у вас осталось 9 (90%)

• Инвентарь - товарное устройство легко доступно из любого ближайшего магазина по отличной цене.

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

• Производительность - при наличии двух устройств в сети SAN они должны находиться в одной комнате. При подходе с использованием обычных компьютеров, если у вас есть 5 офисов, вы можете иметь 2 в каждом офисе с резервированием VPN WAN между офисами. Это означает, что программное обеспечение и связь находятся в локальной сети при времени доступа <1 мс.

• Безопасность - опираясь на высокий уровень избыточности, вы можете легко перестроить узлы как обычный процесс. Хотите перестроить монолитный кластер из 2 серверов? Выйди из руководства. За счет частой перестройки машин (с автоматизацией) вы обновляете программное обеспечение и предотвращаете проникновение хакеров или вирусов в вашу сеть.

Примечание. Вам все равно потребуется резервирование нескольких коммутаторов и шлюзов.