Посоветуйте, как лучше конфигурировать сеть

Здравствуйте.
В наследство от предыдущего администратора достался парк серверов (10 штук) с различными сервисами на них, весьма криво работающими и очень глючащами. Естественно, возникло желание все переделать, но не хватает опыта создания столь большой инфраструктуры серверов. ОС на серверах - Линукс, пара виндовых машин (домен+бэкап), фряха (не знаю зачем - на ней только сервер времени и все).

Что есть:
Создана внутренняя сеть, предположим 192.168.0.0/24, к которой подключены все сервера и из которой посредством шлюза по умолчанию налажен прямой доступ в интернет. Все пользователи пасутся в сети 192.168.1.0/24, которая заведена на squid + sams, собсно, для контроля трафика. Сеть 192.168.0.0 заведена на маршрутизатор Zywall USG300, который NATом прокидывает нужные сервисы наружу и вовнутрь. Есть в наличии около 4 белых IP, но используется только один.

Что хочется: как было бы правильно организовать работу серверов с точки зрения подключения к сети, организации защиты? Ведь получается, что сеть 192.168.0.0 - это DMZ, так? И из нее наружу прокидывать сервисы НАТОм- это нормальная практика? Вообще, полагаться на НАТ в продакшене - это хорошо? Или лучше стараться какие-то определенные сервисы вешать на белые айпишники и защищать файрволом?
Я просто не знаю и хочу только посоветоваться.
Поделитесь опытом, или ткните где почитать про best practices именно по практической стороне организации серверов в средней организации. Я знаю, что это - только опыт, но надоело работать на костылях, хочется сделать все правильно.
Спасибо.

Если у тебя мало адресов, но NAT вполне можно использовать. Не вижу проблем в этом.

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


Воспринимай эту сеть как обычную локалку. Серверы они же тоже члены сети. И не волнуйся. С опытом все придет.

diamond написал:

В наследство от предыдущего администратора достался парк серверов (10 штук) с различными сервисами на них, весьма криво работающими и очень глючащами.
Поделитесь опытом, или ткните где почитать про best practices именно по практической стороне организации серверов в средней организации. Я знаю, что это - только опыт, но надоело работать на костылях, хочется сделать все правильно.

Первое. Вначале надо определиться самому - насколько тебе интересно развивать наследство, которое тебе досталось. Или предпочтительно его поддерживать по принципу "абы работало".
Второе. Если есть интерес, то вначале надо определиться с аппаратной частью наследства. Возможны ситуации, что имеющиеся компьютеры уже "морально" устарели и просятся на свалку. Кроме этого, вполне возможно, что некоторые компьютеры избыточны по отношению к решаемым на них задачам. То есть надо провести инвентаризацию и оптимизацию распределения задач.
Третье. Самое главное правило системного администратора - если он работает, то он плохой администратор. :-) То есть администратор должен настроить свой комплекс так, чтобы самому приходилось работать на нём по минимуму. Отсюда надо строить комплекс, изначально закладывая в него аспекты отказоустойчивости и высокой доступности. То есть определить максимально допустимое время восстановления того или иного сервиса в случае его краха.
Отсюда план работ:
1. Построение высокодоступного кластера хранения данных. Файловый сервер есть всяко. Но вот понравится ли "бизнесу", если файловый сервер (аппаратно) поломается?.. И сколько придется ждать пока админ соорудит файлсервер заново, соорудит и насытит его данными их бэкапа? И сколько оперативных данных будет потеряно при этом?.. Вывод - хранение данных должно быть неубиенным. Решение - кластер "серверов хранения данных". То есть берем два компьютера, в каждый из этих компьютеров ставим по два (минимум) жестких диска и организуем на них, минимум RAID-1 (зеркало). А online-репликацию данных между этими компьютерами делаем или с помощью drbd (самое то для самбовой массовой раздачи), или с помощью glusterfs (я пользую и то и то). На drbd-томах организуем группу томов LVM нужного нам размера, а управление серверами, кто из них master, кто slave-drbd организуем с помощью heartbeat. В результате: в случае выхода из строя любого из дисков (а это самое вероятное событие) любой из наших серверов ХД можно выключить, диск неспешно заменить, перестроить RAID-массивы и включить все это дело обратно, в эксплуатацию. У юзерей пауза - в несколько секунд, не больше...
Да, всё это будет хорошо работать, если канал связи между этими серверами, минимум, гигабит. То есть, гигабитная сеть имеет примерно ту же пропускую способность, что и типовые жесткие диски, те же 70-80 мегабайт в секунду.

2. Итак, мы построили СХД высокой доступности. Далее - возвращаемся к оптимизации сервисов. Мы выяснили, что есть несколько серверов, каждый из которых тянет некие уникальные сервисы. При этом, вполне возможно, что сервера эти и не загружены (по top) совершенно. Возможно ли совместить эти сервисы на одном физическом компьютере и сделать так, чтобы они не мешали друг другу и чтобы юзеры не заметили совершенно такого совмещения, чтобы как они работали, так и продолжали бы работать? Вполне возможно и легко осуществимо. Наше решение лежит на пути построения виртуальных машин, которым мы будем выделять потребное количество процессоров и памяти. Если для кластера СХД нам нужны были компьютеры производительные только в части дисковой подсистемы и сети, то для сервера виртуальных машин (а их можно нагрузить на один физический компьютер много) надо иметь и запас процессоров и памяти на этом сервере. Итак, раскуриваем KVM. Организуем на СХД том, в котором будет жить виртуальная машина, раздадим его по iSCSI, а на сервере виртуальных машин подключимся к этому тому, смонтируем его и поднимем в этом томе нашу виртуальную машину (в которой будет жить наш глючный сервис), например, почтовый сервер. Или что иное. Аккуратно его настраиваем и в час Х включаем его вместо физического сервера, который тянул этот сервис. То же самое делаем и на иные сервисы, например, на шлюз доступа в интернет, на сервер VoIP, файловый сервер и так далее. Тот же виндовый сервер прекрасно в виртуалке жить будет. В результате один мощный компьютер потянет на себе несколько виртуальных машин, каждая из которых будет решать свои задачи. Одно только условие - не стоит писать данные виртуальной машины в "образ" виртуальной машины. Лучше данные из виртуальных машин писать на те же iSCSI-диски или гластерные тома, полученные от СХД, вовне (причин много и все, на мой взгляд, весомы). А чем сама виртуалка реже меняется, тем админу спокойнее. Крах одной из виртуальных машин не потянет за собой краха иных машин. А восстановление её - проблема накатить из образа, с резервной копии?

3. Итак - крах хоста, на котором живут виртуальные машины... Смертельно? Отнюдь. Опрять же раскуриваем тему кластеризации. Только здесь нам на помощь придет не простенький heartbeat, а более мощный (и более глючный) pacemaker. Делаем двухнодовый pacemaker-кластер, на этих нодах поднимаем iscsi-initiator и набор виртуальных KVM-машин. И организуем средствами pacemaker'а живую миграцию виртуальных машин на выжившую ноду. И, в это время, спокойно занимаемся ремонтно-восстановительными работами на рухнувшем сервере. Юзеры их не видят и продолжают работать в обычном режиме. Здесь маленькая засада есть - нельзя на одной ноде поднимать и iSCSI-Target и iSCSI-инициатор. В случае переключения нод - всё встанет колом. Если этого не делать - всё будет работать беспроблемно.

Выводы: после проведения таких работ мы получим систему из 4 физических компьютеров, два из которых тянут хранение данных и другая пара - виртуальные машины с теми или иными сервисами, нужными нашему бизнесу. Ни о каких десятках серверов речи больше идти не будет. Всё серверное хозяйство прекрасно уместится в стандартном телекоммуникационном (серверверном) шкафу, из которого можно легко сделать принудительный отвод нагретого воздуха (например, в вентиляционную шахту) и не сильно париться с вопросами климата серверной. Ну и если потребуется еще что развернуть - всё делается не на новом физическом компьютере, а в среде виртуализации. Виртуалок можно строгать десятками. Лишь бы под них ескости СХД хватило. А расчет ёмкости прост: одна linux-виртуалка - минимум, 8 гигабайт. Оптимум - 12. Хватит за глаза. Ну, и все сервера - с RAID-1, минимум.

Сделаешь так и будет тебе счастье. Работать будет автоматика, а не ты, в режиме ошпаренной кошки, ликвидировать те или иные неисправности на комплексе.
=======================
Описанное - есть мой личный best practices. А конкретное сетеплетение - это уже само получается так как надо. Ну и безопасность - нет никакой разницы для малого бизнеса ты систему строишь, для среднего или для крупного. Везде одни и те же требования. Которые подлежат обязательному исполнению. Например, иметь крепкие пароли, по крайней мере для рута, отделять сегмент юзерей отдельно от выделенного сегмента серверов (ну и межсетевое экранирование для контроля доступа). Кроме, разве что одного требования - требования применять сертифицированные средства защиты. Но это требование возникает на крупном бизнесе и только там, где есть взаимодействие с органами госвласти (или что-то похожее).

diamond написал:

Здравствуйте.
с различными сервисами на них, весьма криво работающими и очень глючащами.

А что с ними?