Назад | Перейти на главную страницу

3 сервера, это кластер?

На данный момент у меня есть один сервер Ubuntu, 9.10, работающий с простым общим ресурсом Samba, почтовым сервером, DNS-сервером и DHCP-сервером. В основном это просто для обмена файлами и почтового сервера.

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

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

Было бы для меня более выгодным, если бы все 3 сервера, на которых выполнялись одни и те же службы, делали одно и то же с каким-то кластером с балансировкой нагрузки?

Я не совсем уверен, с чего начать, или как сделать такую ​​настройку, когда все 3 сервера идентичны, но, возможно, один действует как основной балансировщик нагрузки ??

Если кто-то может указать мне правильное направление или это просто звучит как одно из тех Enterprise Cloud, которые теперь являются настройкой по умолчанию в Ubuntu Server 9.10+, тогда я пойду по этому пути.

Заранее приветствую.

Энди

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

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

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

Это неуклюже, но если это приемлемо для вашей ситуации, с логистикой справиться несложно.

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

Предполагается, что у вас есть хороший план резервного копирования.

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

Плюсы довольно большие; несколько виртуальных серверов упрощают воссоздание и миграцию серверов по мере необходимости, а также разделение служб и устранение неполадок. Одно ошибочное обновление не приведет к потере трех или четырех служб, когда выйдет из строя сервер, только одна виртуальная машина. Если вы используете VMWare, легко перейти на их дорогостоящие серверы, если вы решите сделать это в будущем, а виртуальные машины отлично подходят для создания тестовых стендов. Вы можете делать снимки серверов и ремонтировать или обслуживать свои физические серверы после первой миграции своих систем на один из других серверов виртуальных машин, и пользователи не узнают об изменениях. Также очень удобно делать снимки состояний системы. При необходимости вы можете сохранить весь сервер на внешнем жестком диске и перенести его на другой компьютер!

У вас также есть возможности для виртуализации; Xen / KVM самостоятельно с открытым исходным кодом, ESXi, ESX, Citrix и т. Д. С различными ценами (бесплатно до нескольких тысяч долларов) и поддержкой (самостоятельно бесплатно или несколько тысяч долларов за полную поддержку до wazoo).

Я бы протестировал его и посмотрел, подходит ли он для вашей бизнес-ситуации.

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

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

Первое, что я хотел бы сделать, это попытаться распределить нагрузку на разные компьютеры: пусть первый выполняет только электронную почту, DHCP и DNS, второй и третий могут быть настроены для обработки разных общих ресурсов самбы. Таким образом, использование самбы не влияет на электронную почту, и вы несколько балансируете самбу между двумя компьютерами. Конечно, это не идеально, но это хорошее начало. Затем убедитесь, что каждый сервер настроен таким образом, что функция другого компьютера может быть активирована несколькими нажатиями клавиш в случае сбоя (настройте службу, но не активируйте ее) и, конечно, что у вас есть последние данные с другого сервера на нем, насколько это возможно (резервное копирование, резервное копирование, резервное копирование!).

После того, как все это будет сделано, вы можете приступить к оптимизации всей установки. Во-первых, почему сервер вообще должен выйти из строя? Ожидается, что они будут стабильными, а если это не так, что-то серьезно не так. Во-вторых: по какой причине вы не можете получить доступ к электронной почте, когда кто-то выполняет передачу больших файлов? Сеть переполнена, есть ли у вас проблемы со скоростью диска или даже с памятью / или мощностью процессора? Что-то можно сделать с этой проблемой? Может быть, заменить коммутаторы и сетевые карты сервера на Gigabit Ethernet вместо 100MB? Ввод дополнительной оперативной памяти или RAID-контроллера с новыми, более быстрыми дисками?

Я бы использовал один сервер для своих инфраструктурных нужд (DNS, DHCP ..) плюс электронная почта. Два других я бы создал как кластер самбы http://wiki.samba.org/index.php/Clustered_Samba.