концепт организации сети в инженерном микроофисе

Moderator: Little Muk

Post Reply
костя_задунайский
Posts: 83
Joined: 03 Oct 2011, 22:28
ник с it-ru.de: верифицирован

концепт организации сети в инженерном микроофисе

Post by костя_задунайский »

Народ привет! У одного бывшего форумчанина тут вопрос есть. Помогите советом!

Code: Select all

Покритикуйте, пожалуйста, концепт организации сети в инженерном микроофисе (3+1 рабочих места).

Точка входа: рутер (z.B. FritzBox), у него свой аппаратный Firewall.

Далее сеть разделяется на два сегмента: 

	1. Win 
	2. Lin

Разделение требуется по двум причинам - инженерный софт для разработки заточен под 	RHEL/Centos 6 или 7 и безопасность чувствительных данных заказчиков. 

1. Сегмент Win почти исключительно для офиса, мыла, документов, скайпа и интернет. 
В нем живут ноутбуки под Windows, доступ к Lin-сегменту через VNC или аналог Open Text Exceed on Demand (EoD) на редкий случай работы вне офиса. Связь с рутером по WLAN. 

У Open Text довольно мутная ценовая и сервисная политика, поэтому приветствуется совет, чем заменить, желательно бесплатным (не обязательно) и не требующим поддержки.

2. В сегменте Lin живут thin clients, файл сервер, мэйл сервер, веб-сервер и compute farm, вся связь по LAN.

	Серверная часть в этом сегменте разделена на две: 

	2.1 один сервер со своим аппаратным сетевыми экраном обслуживает веб и мэйл
	2.2 еще один спрятанный за 2.1. есть по сути compute farm и файловое хранилище

	+ изредка вкпючаемый для бэкапов NAS 
	+ UPC

Thin clients (в варианте полной сборки с периферией) грузятся с 2.2., собственный объем дискового пространства небольшой, т.   к. nfs и рабочие данные хранятся в 2.2. в версионированном виде. Ни для чего кроме работы не используются.

	Организация п. 2.1
	Дистро: дебиан
	Железо: что-нибудь малопотребляющее от AMD, возможно с ядром А5х и trusted zone (или даже 	сразу ARM), 1GB RAM, два диска по 250GB в софтверном RAID 6, хотсвоп не критичен 

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

	Организация п. 2.2
	Дистро: дебиан
	Железо: две фермы с AMD APU PRO A12-8800B, 32GB ECC RAM, два диска 3TB для 	файлохранилища, в софтверном RAID 6, хотсвоп не критичен. Для бэкапов отдельный дисковый 	массив (NAS, либо же внешние диски).
	Server/Client: LXC для запуска centos на сервере + загрузка с thin client

	Почему LXC? Нет оверхеда в 10-20% как в виртуалке, почти чистый перформанс хост-системы. 	Кроме 	того, если не ошибаюсь, в LXC можно динамически назначать ресурсы (свой балансер?)

Софт для моделирования параллелится, т.е. из трех рабочих мест либо каждый займет по два треда + 8GB RAM, либо один может занять три таких пары (два оставшихся ― система и резерв), остальных в очередь от Sun Grid/OGS, LSF или LBS. Аналогично, совет лучшего (фришного) балансера приветствуется.

Софт так же чекаутит лицензии, которые лезут в интернет на сервер поставщика софта. Пока не придумал, где их держать - на веб сервере или на ферме, в связи с этим еще два вопроса - нужен ли сетевой экран ферме и существует ли скремблинг портов? К примеру мне нужно с виндового ноута, находясь вне вне офиса, достать файлы или запустить посчитать что-то на ферме в кластере, соответственно нужен защищенный доступ к ферме и хранилищу, как это лучше организовать?


К сожалению по теме secure gateways опыта нет совсем, поэтому ничего лучшего не придумал, кроме как просто назначение и маскирование комбинаций портов в сетевых экранах на каждом этапе сетки для каждой сессии. Геморройно, но если редко, то терпимо. Сканер портов найдет порты у фрица, увидит ли далее не уверен, но вопрос безопасного проброса с фермы-хранилища остается открытым. 

Почему дебиан в качестве основной системы? Потому что есть некоторый скромный опыт установки и поддержки в embedded системе на ARM, а готовые конфиги debian host/centos guest гуглятся на раз. Сентосом на клиентах пользуюсь, но ковырять и администрировать еще и centos сервер может быть интересно, но не очень хочется - я не айтишник и не админ, должен в первую очередь заниматься своими инженерными проектами, поэтому хотелось бы максимально быстро разобраться в своей сетке и настроить ее самому в течение следующих четырех месяцев. 

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

Решения от HP, lenovo или Fujitsu видел, по ряду причин и в первую очередь по цене (такое кастомное решение обойдется скорее всего очень дорого) не подойдут. И все равно нужен отдельный веб/мэйл сервер, по требованиям безопасности и чтобы не отнимать ресурсы у фермы на такие мелочи.

На общие вопросы „почему XXX, ведь есть же YYY?“ ответить за недостатком знаний вряд ли смогу, иначе бы не спрашивал. Наоборот, было бы интересно выслушать аргументы против ХХХ и за YYY и особенно за совместимость YYY с остальными частями концепта.

Естественно возникнут и такие вопросы: для чего тонкие клиенты, для чего дублировать функционал ноут+иксы в VNC/EoD?

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

Собственно скорее по причине а)+б) и собственноручная хард и софтверная сборка клиентской и серверной частей - читай полный контроль за system & design environment - есть посыл клиенту: все что с нашей стороны мы могли обеспечить - мы обеспечили.

В идеале для работы вне офиса и для заказчика нужно организовать доступ с двухфакторной авторизацией, например SecurID+VPN/OSSH еtc... Но на начальном этапе это не обязательно.

Охотно прислушаюсь к совету и по железу, но хотелось бы, чтобы камень в пике не выходил за 10W на тред и поддерживал AES-NI.

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

Заранее спасибо за конструктив.
User avatar
Китаец
Posts: 11485
Joined: 22 Sep 2011, 09:35
ник с it-ru.de: верифицирован
Contact:

Re: концепт организации сети в инженерном микроофисе

Post by Китаец »

Покритикуйте, пожалуйста, концепт организации сети в инженерном микроофисе (3+1 рабочих места).

Точка входа: рутер (z.B. FritzBox), у него свой аппаратный Firewall.

Далее сеть разделяется на два сегмента:

1. Win
2. Lin

Разделение требуется по двум причинам - инженерный софт для разработки заточен под RHEL/Centos 6 или 7 и безопасность чувствительных данных заказчиков.

1. Сегмент Win почти исключительно для офиса, мыла, документов, скайпа и интернет.
В нем живут ноутбуки под Windows, доступ к Lin-сегменту через VNC или аналог Open Text Exceed on Demand (EoD) на редкий случай работы вне офиса. Связь с рутером по WLAN.

У Open Text довольно мутная ценовая и сервисная политика, поэтому приветствуется совет, чем заменить, желательно бесплатным (не обязательно) и не требующим поддержки.

2. В сегменте Lin живут thin clients, файл сервер, мэйл сервер, веб-сервер и compute farm, вся связь по LAN.

Серверная часть в этом сегменте разделена на две:

2.1 один сервер со своим аппаратным сетевыми экраном обслуживает веб и мэйл
2.2 еще один спрятанный за 2.1. есть по сути compute farm и файловое хранилище

+ изредка вкпючаемый для бэкапов NAS
+ UPC

Thin clients (в варианте полной сборки с периферией) грузятся с 2.2., собственный объем дискового пространства небольшой, т. к. nfs и рабочие данные хранятся в 2.2. в версионированном виде. Ни для чего кроме работы не используются.

Организация п. 2.1
Дистро: дебиан
Железо: что-нибудь малопотребляющее от AMD, возможно с ядром А5х и trusted zone (или даже сразу ARM), 1GB RAM, два диска по 250GB в софтверном RAID 6, хотсвоп не критичен

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

Организация п. 2.2
Дистро: дебиан
Железо: две фермы с AMD APU PRO A12-8800B, 32GB ECC RAM, два диска 3TB для файлохранилища, в софтверном RAID 6, хотсвоп не критичен. Для бэкапов отдельный дисковый массив (NAS, либо же внешние диски).
Server/Client: LXC для запуска centos на сервере + загрузка с thin client

Почему LXC? Нет оверхеда в 10-20% как в виртуалке, почти чистый перформанс хост-системы. Кроме того, если не ошибаюсь, в LXC можно динамически назначать ресурсы (свой балансер?)

Софт для моделирования параллелится, т.е. из трех рабочих мест либо каждый займет по два треда + 8GB RAM, либо один может занять три таких пары (два оставшихся ― система и резерв), остальных в очередь от Sun Grid/OGS, LSF или LBS. Аналогично, совет лучшего (фришного) балансера приветствуется.

Софт так же чекаутит лицензии, которые лезут в интернет на сервер поставщика софта. Пока не придумал, где их держать - на веб сервере или на ферме, в связи с этим еще два вопроса - нужен ли сетевой экран ферме и существует ли скремблинг портов? К примеру мне нужно с виндового ноута, находясь вне вне офиса, достать файлы или запустить посчитать что-то на ферме в кластере, соответственно нужен защищенный доступ к ферме и хранилищу, как это лучше организовать?


К сожалению по теме secure gateways опыта нет совсем, поэтому ничего лучшего не придумал, кроме как просто назначение и маскирование комбинаций портов в сетевых экранах на каждом этапе сетки для каждой сессии. Геморройно, но если редко, то терпимо. Сканер портов найдет порты у фрица, увидит ли далее не уверен, но вопрос безопасного проброса с фермы-хранилища остается открытым.

Почему дебиан в качестве основной системы? Потому что есть некоторый скромный опыт установки и поддержки в embedded системе на ARM, а готовые конфиги debian host/centos guest гуглятся на раз. Сентосом на клиентах пользуюсь, но ковырять и администрировать еще и centos сервер может быть интересно, но не очень хочется - я не айтишник и не админ, должен в первую очередь заниматься своими инженерными проектами, поэтому хотелось бы максимально быстро разобраться в своей сетке и настроить ее самому в течение следующих четырех месяцев.

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

Решения от HP, lenovo или Fujitsu видел, по ряду причин и в первую очередь по цене (такое кастомное решение обойдется скорее всего очень дорого) не подойдут. И все равно нужен отдельный веб/мэйл сервер, по требованиям безопасности и чтобы не отнимать ресурсы у фермы на такие мелочи.

На общие вопросы „почему XXX, ведь есть же YYY?“ ответить за недостатком знаний вряд ли смогу, иначе бы не спрашивал. Наоборот, было бы интересно выслушать аргументы против ХХХ и за YYY и особенно за совместимость YYY с остальными частями концепта.

Естественно возникнут и такие вопросы: для чего тонкие клиенты, для чего дублировать функционал ноут+иксы в VNC/EoD?

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

Собственно скорее по причине а)+б) и собственноручная хард и софтверная сборка клиентской и серверной частей - читай полный контроль за system & design environment - есть посыл клиенту: все что с нашей стороны мы могли обеспечить - мы обеспечили.

В идеале для работы вне офиса и для заказчика нужно организовать доступ с двухфакторной авторизацией, например SecurID+VPN/OSSH еtc... Но на начальном этапе это не обязательно.

Охотно прислушаюсь к совету и по железу, но хотелось бы, чтобы камень в пике не выходил за 10W на тред и поддерживал AES-NI.

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

Заранее спасибо за конструктив.
прокручивать зело неудобно
Image
Post Reply