Если вы не можете себе позволить или вам не нужен кластер или запасной сервер, ожидающий подключения в случае сбоя, похоже, что вы могли бы разделить услуги, предоставляемые одним мощным сервером, на два менее мощных сервера. Таким образом если сервер A выйдет из строя, клиенты могут потерять доступ, например, к электронной почте, а если сервер B выйдет из строя, они могут потерять доступ к системе ERP.
Хотя на первый взгляд это кажется более надежным, разве это не увеличивает вероятность отказа оборудования? Таким образом, любой сбой не окажет такого сильного влияния на производительность, но теперь вы настраиваете себя на вдвое больше сбоев.
Когда я говорю «менее мощно», я имею в виду более низкие характеристики компонентов, а не более низкое качество. Итак, одна спецификация машины для визуализации против двух серверов для меньшей нагрузки каждый.
Часто рекомендуется использовать SAN, чтобы вы могли использовать кластеризацию или миграцию для поддержания работы служб. Но как насчет самой SAN? Если бы я должен был вкладывать деньги в то, где может произойти сбой, он не будет на базовом серверном оборудовании, это будет как-то связано с хранилищем. Если у вас нет какой-то резервной SAN, то эти резервные серверы не вселили бы во мне особого чувства уверенности. Лично для меня было бы разумнее инвестировать в серверы с резервными компонентами и локальными дисками для небольшой операции. Я вижу выгоду в более крупных операциях, когда цена и гибкость SAN являются рентабельными. Но для небольших магазинов я не вижу аргументов, по крайней мере, в пользу отказоустойчивости.
Все сводится к управлению рисками. Проведение надлежащего анализа затрат / рисков ваших ИТ-систем поможет вам выяснить, на что потратить деньги и с какими рисками вы можете или должны столкнуться. За все связано определенную стоимость ... включая высокую доступность и время простоя.
Я работаю в небольшом месте, поэтому я понимаю эту борьбу, и компьютерный компьютерщик во мне не хочет, чтобы нигде не было единой точки отказа, но затраты на это на каждом уровне нереальны. Но вот несколько вещей, которые мне удалось сделать, не имея огромного бюджета. Однако это не всегда означает устранение единой точки отказа.
Сетевая граница: У нас есть 2 подключения к Интернету: T1 и Comcast Business. Планируется перенос нашего брандмауэра на пару старых компьютеров, на которых работает pfSense с использованием CARP для HA.
Сеть: Получение пары управляемых коммутаторов для ядра сети и использование связывания для разделения критически важных серверов между двумя коммутаторами предотвращает отказ коммутатора от разрушения всего хранилища данных.
Серверы: Все серверы имеют RAID и резервные блоки питания.
Сервер резервного копирования: У меня есть более старая система, которая не так мощна, как основной файловый сервер, но у нее есть несколько больших sata-дисков в raid5, которые ежечасно делают снимки основного файлового сервера. У меня есть сценарии для переключения ролей в качестве основного файлового сервера, если он выйдет из строя.
Сервер резервного копирования вне офиса: Подобно резервному копированию на месте, мы делаем еженощное резервное копирование на сервер через туннель vpn к одному из домов владельцев.
Виртуальные машины: У меня есть пара физических серверов, которые запускают ряд служб внутри виртуальных машин с использованием Xen. Они запускаются из общего ресурса NFS на главном файловом сервере, и я могу выполнять миграцию в реальном времени между физическими серверами, если возникнет необходимость.
Я думаю, что это вопрос с множеством ответов, но я бы согласился, что во многих небольших магазинах решение с несколькими серверами работает, и, как вы говорите, по крайней мере, что-то продолжает работать, если произойдет сбой. Но это зависит от того, что не удается.
Очень сложно охватить все базы, но могут помочь резервные источники питания, хорошее качество питания и хорошее резервное копирование.
Мы использовали Backup Exec System Recovery для некоторых критически важных систем. Не столько для ежедневного резервного копирования, сколько как средство восстановления. Мы можем выполнить восстановление на другом оборудовании, если оно доступно, и мы также используем программное обеспечение для преобразования образа резервной копии в виртуальную машину. Если сервер выходит из строя и нам нужно дождаться ремонта оборудования, мы можем запустить виртуальную машину на другом сервере или рабочей станции и продолжить работу. Не идеально, но его можно быстро запустить.
Что касается SAN: почти все, что вы используете, будет избыточным. Даже если это единый корпус, внутри будут два источника питания, два разъема и две «головки», каждая со связями со всеми дисками. Даже такой простой продукт, как MD3000, продаваемый Dell, имеет все эти функции. Сети SAN созданы для того, чтобы быть ядром ваших устройств, поэтому они созданы, чтобы выдержать практически любой случайный отказ оборудования.
При этом вы понимаете, что избыточность - не всегда лучший вариант. ОСОБЕННО, если это увеличивает сложность. (и будет). Лучше задать вопрос ... «Сколько компания согласится с простоями». Если потеря вашего почтового сервера на день или два не имеет большого значения, то вам, вероятно, не стоит беспокоиться о двух из них. Но если из-за сбоя веб-сервера вы каждую минуту теряете реальные деньги, возможно, вам стоит потратить время на создание подходящего кластера для этого.
Чем больше у вас серверов, тем больше шансов, что что-то сломается, это один из способов взглянуть на это. Во-вторых, если один сломается, вы получите скрип на 100%, как вы и говорите.
Как вы сказали выше, наиболее частый аппаратный сбой - это HD. Независимо от того, сколько операций вы хотите разделить между собой, вам необходимо использовать RAID для хранения.
Я бы проголосовал за пару серверов (конечно, с RAID) вместо одного массивного, как за стабильность работы, так и за производительность. Меньше программного обеспечения, запрашивающего ресурсы, меньше беспорядка, больше дисков для чтения / записи и т. Д.
Я бы лично выбрал несколько серверов. Я не думаю, что в этом сценарии более вероятен отказ оборудования. Да, у вас есть больше оборудования, которое может выйти из строя, но вероятность того, что любой данный юнит выйдет из строя, должна быть постоянной.
Наличие нескольких серверов в конфигурации без резервирования / без высокой доступности дает мне возможность переложить часть работы на другой сервер в случае сбоя. Итак, скажем, мой сервер печати выходит из строя. Если я могу подключить несколько принтеров к файловому серверу во время ремонта сервера печати, влияние на операции уменьшится. И вот где это действительно важно. Мы часто говорим об аппаратном резервировании, но оборудование - это только инструмент для обеспечения непрерывности работы.
Я работаю в небольшом магазине (один человек в ИТ-отделе) и ни при каких обстоятельствах не буду менять несколько серверов на один. Если какой-либо из серверов выйдет из строя, у меня есть возможность добавить недостающие службы на другой компьютер или даже просто настроить их на запасном ПК. Мы можем жить с отключением на час или два для большинства вещей, но мы не можем жить с полным отключением всех систем. Хотя я могу заменить любой из наших серверов на ПК, по крайней мере временно, у меня нет или я могу легко получить что-нибудь достаточно мощное, чтобы заменить все сервера сразу.
В вашем исходном сообщении предполагается, что вы не можете позволить себе кластер, но вы рассматриваете решения с двумя серверами (не включая резервные копии). Это будет означать, что у вас, скорее всего, есть три сервера, которых достаточно для запуска кластера.
Существуют промежуточные решения, которые позволяют избежать использования SPoF и по-прежнему подходят для малых и средних предприятий: репликация от узла к узлу без хранения SAN.
Это поддерживается, например, Proxmox (но я думаю, что это также поддерживается XCP-ng / XenServer и, вероятно, ESXi).
Давайте рассмотрим установку из 3 узлов. Все с RAID, резервным блоком питания, резервированной сетью.
Тогда два варианта:
Такой тип установки может выдержать сетевой сбой, полный или основной отказ узла (любой из трех) с временем простоя около 1 минуты (примерно время, необходимое для загрузки виртуальной машины). Обратной стороной является потеря данных с момента последней репликации (которая в зависимости от ваших настроек и производительности оборудования может составлять от 1 минуты до нескольких часов).
При выборе 2-го варианта (виртуальная машина обычно разделена между узлами A и B) вы должны определить приоритеты, которым разрешено возвращаться в оперативный режим. Поскольку нагрузка на виртуальную машину обычно распределяется между двумя серверами, то, что все они работают на одном узле, может исчерпать оперативную память узла или перегрузить ЦП.
«Хотя на первый взгляд это кажется более надежным, разве это не увеличивает вероятность отказа оборудования?»
Никогда не бывает так просто, большие мощные серверы могут быть сделаны лучше или хуже. У них могут быть детали более высокого качества, но они могут выделять больше тепла и не охлаждаться должным образом. На мощном сервере больше ОЗУ, больше процессоров и т. Д., Так что, в конце концов, возможно, у вас будет столько же процессоров в обоих сценариях, так что, возможно, сервер - не то устройство, о котором стоит думать.
Я думаю, что из-за сложности возможностей выигрывает то, что является наиболее экономичным. Если вам нужно платить за лицензии, 1 большой сервер может быть дешевле, чем несколько меньших серверов, в зависимости от структуры лицензирования.
Мой подход по умолчанию - избегать любой централизованной инфраструктуры. Например, это означает нет SAN, нет балансировщика нагрузки. Такой централизованный подход также можно назвать «монолитным».
Как разработчик программного обеспечения я работаю с инфраструктурой заказчика. Это может означать использование собственного частного центра обработки данных или использование чего-то вроде AWS. Поэтому я обычно не контролирую, используют ли они SAN или нет. Но мое программное обеспечение обычно распространяется на нескольких клиентов, поэтому я создаю его так, как будто оно будет работать на отдельных машинах изолированно в сети.
Пример электронного письма
Электронная почта - это странно, потому что это устаревшая система (которая работает). Если бы электронная почта была изобретена сегодня, она, вероятно, использовала бы API-интерфейсы RESTFul на веб-серверах, а данные были бы в базе данных, которую можно было бы реплицировать с помощью обычных инструментов (репликация транзакций, инкрементное резервное копирование).
Решение для архитектуры программного обеспечения состоит в том, что веб-приложение будет подключаться к одному из списка доступных узлов (случайным образом), а если это недоступно, оно будет пытаться подключиться к другому узлу (случайным образом). Клиент может быть отключен от сервера, если он слишком занят. Здесь нет необходимости в балансировщике нагрузки для подключения к веб-ферме; и для высокой доступности нет необходимости в SAN. Также возможно сегментировать базу данных по отделам или географическим регионам.
Товар означает ...
Таким образом, вместо дорогих 1 или 2 серверов и SAN с мерами внутреннего резервирования вы можете использовать несколько обычных маломощных недорогих машин.
Простота - резервирование исходит исключительно от количества устройств. Вы можете легко проверить свою избыточность по количеству машин. А вы правильнее оцените, что у них больше шансов на неудачу, и подготовьтесь к этому.
Процент избыточности - Если у вас 2 сервера, если один выходит из строя, у вас остается 1 (50%). Если у вас 10 стандартных серверов, а один выходит из строя, у вас осталось 9 (90%)
Инвентарь - товарное устройство можно легко приобрести в любом ближайшем магазине по отличной цене.
Совместимость - с оптоволоконными каналами и всевозможными стандартами для форматов дисковых томов, стандартных устройств и архитектуры программного обеспечения означает, что вы не привязаны к одной модели или бренду устройства.
Производительность - Если к SAN подключено 2 устройства, они должны находиться в одной комнате. При использовании массового машинного подхода, если у вас 5 офисов, у вас может быть 2 в каждом офисе, с резервированием VPN WAN между офисами. Это означает, что программное обеспечение и связь находятся в локальной сети со временем доступа <1 мс.
Безопасность - опираясь на высокий уровень избыточности, вы можете легко перестраивать узлы как обычный обычный процесс. Хотите перестроить монолитный кластер из 2 серверов? Вытащите руководство. Часто перестраивая машины (с автоматизацией), вы обновляете программное обеспечение и предотвращаете проникновение хакеров или вирусов в вашу сеть.
Примечание. Вам все равно потребуется резервирование нескольких коммутаторов и шлюзов-маршрутизаторов.