Задать вопрос
@KTG
сети

Как лучше организовать IT-инфраструктуру предприятия?

Предложили в свободное время попробовать себя в организации ИТ-инфраструктуры предприятия с нуля. Сеть, сервера, хранилища данных ну и всё прочее сопутствующее. В каждой области (кроме АТС) занимался какими-то мелкими и конкретными задачами, устранял отдельно взятые проблемы, но вкупе не доводилось работать. Так что основная мотивация прокачать свои навыки в этой области, поэтому преимущество не малознакомым технологиям, а скорей наиболее верным решениям.
Вначале расскажу своё видение, а в целом хотел посоветоваться с сообществом и получить какие-нибудь рекомендации. Плюс есть конкретные вопросы по некоторым решениям. Основные вопросы по выбору оборудования.
UPD: мельком пока гуглю статьи на данную тематику, разумеется могу заблуждаться, углубляться буду по мере прохождения этапов. Сейчас накидываю лишь примерный план и определяю, с чем придется работать.
Запас времени есть, на обдумывание 1 месяц. Потом месяц на детальное изучение текущих дел, на разработку чернового и рабочего плана. Думаю можно многое освоить.

На данный момент имеется:
Небольшое здание, 4 этажа с маленькими кабинетами на 2-3 человека и такой-же небольшой пристрой. Персонал: 40-50.
Аналоговая АТС с десятком внешних номеров (обслуживается поставщиком) - вся на скрутках.
Старенький стоечный сервер (по характеристикам не скажу, но когда я их смотрел определенно принял решение оставить его под мелкие нужды) и внешний накопитель - файловое хранилище.
Непонятная сеть, похожая на домашнюю. От провайдера кабель идет в сервер, из него в 5 портовый свич, из него в точно такие же свичи... в целом 2-3 свича и только потом в комп. Ни один из них не управляемый, но с поддержкой DHCP раздающих адреса динамически, что регулярно вызывает конфликты.
Из ПО пара конфигураций 1С на 5-10 пользователей каждая.
Зоопарк пользовательских ПК, разброс лет 15, вперемешку с моноблоками разных производителей и полной анархией в политиках доступа.
И неизвестно, что на удаленных филиалах.
Если представили эту картину и даже если вы далеки от подобной сферы, то несомненно пришли в замешательство и поняли, что так дальше нельзя.

На что установлен ориентир:
В первую очередь, разумеется, стабильная работа с отказоустойчивой системой.
После проведения основной модернизации хотелось бы сократить стоимость (время/силы/деньги) поддержки на устранение неисправностей и непредвиденных ситуаций.
Масштабируемость и дальнейшее развитие уже в виде дополнительных программных сервисов (СЭД, СКД, тикет-системы и т.д.) и плюшки вроде мониторинга ИТ-ресурсов.
Сведение всего плана модернизации к единовременным разумным тратам на оборудование за счет перехода на свободное ПО.
Ну и очень сильное желание всё сделать по феншую.

Что вижу в голове (с вопросами):
При выборе оборудования и технологий хотелось бы закладывать рост компании в 2 раза - количество человек/оборудования. Если где ошибаюсь - смело поправляйте.

Берем нормальную стойку для серверного и сетевого оборудования.
1. Сеть
В первую очередь хотелось бы перекроить в нормальные короба с выводом розеток, а не набивать провода в тонкие кабель-каналы.
Кабелем выберем экранированную витую пару.
Тут встает выбор:
1. Или на каждый этаж заводить управляемый коммутатор из дешевого сегмента (D-Link какой-нибудь на 16-24 портов), что не особо нравится в плане расширения, поэтому склоняюсь к второму варианту;
2. Разориться на парочку многопортовых стоечных коммутаторов и вести к каждой машине свой кабель.
На сколько нарыл в интернете можно взять два по 48 портов и объединить их.
Помимо пользовательских ПК, будут сетевые МФУ, возможно ещё камеры, ip-телефония и т.д.

Дальше, т.к. в наличии есть филиалы, то не обойтись без маршрутизатора. Он в дальнейшем поможет организовать и активный резервный канал связи, соответственно два WAN порта + wifi модуль.
WiFi будет для пользовательских мобильных устройств через резервный канал, т.к. основной канал планируется резать от "паразитного" трафика - только рабочие ресурсы. Почему не отдельные модемы на этажах, а репитеры? Чтобы иметь более гибкий контроль, как в плане "мертвого" основного канала, чтобы отключить "левак", так и в плане фиксации трафика с устройств для избежания слива информации в интернет (защита от дурака, который сливает через телефон фото документов в общественный доступ, но забывает что автоматом подключился к рабочей вафле. Подглядел в одной конторе, там так 2 дурачков за полгода поймали) . Все устройства будут регистрироваться в обязательном порядке.

С филиалами пока еще неизвестно что там есть конкретно и что будет, главное иметь возможность из главного здания поднять VPN и впустить их при необходимости в сеть. В оборудовании я мало разбираюсь, но на слуху две фирмы: Mikrotik и Cisco. Одни подороже, другие подешевле. Верен ли мой набросок сети, насколько он правильный? И если всё верно, то какое сетевое оборудование вы бы посоветовали? Разумеется стремимся к более бюджетным вариантам, за брендами не гонимся.

2. Сервер
Тут меня одолевают смутные сомнения, взять два сервера и объединить их в кластер для оперативной подмены или в целях экономии взять один и считать, что ничего с ним не случиться.
Хотелка для серверов: недорогая стоечная kvm-консоль с IP.

По серверам мысль такая:
Про кластер из двух новых серверов, если позволит бюджет, я уже сказал (пока не углублялся, но как понял, во время работы синхронизируется, можно настроить распределение нагрузок и при выходе одного сервера из строя идет полное переключение на второй). Используем виртуализацию на свободном ПО. Остановился на Citrix XenServer (пару раз тыкал кнопочки, читал сравнения с аналогичными гипервизорами). В пул добавляем сервера (тыкал как пользователь пару раз через KDE, но понял, что для роста в профессиональном плане освоить его надо получше).
1 виртуальный сервер - Linux Ubuntu: Работает как DHCP-сервер (или лучше отдать роль коммутатору/маршрутизатору?) и домен-контроллер и служба каталогов (LDAP. Беглый анализ показал что популярности Samba) и сервер лицензий.
2 виртуальный сервер: ОС будет зависеть если все таки отыщется лицензия на MS SQL и Windows Server. Если нет, то ставим Linux Ubuntu и отдаем сервер под базу данных на PostgreSQL. Приоритет ресурсов: память.
3 виртуальный сервер Linux Ubuntu: Отдаём под 1С. Приоритет ресурсов: проц.

Старый слабенький сервер так же виртуализируем, но в пуле будет два сервера:
1 виртуальный сервер Linux Ubuntu: Под веб-сервер для внутренних нужд - СЭД, Внутренний корпоративный портал и т.д.
2 виртуальный сервер Linux Ubuntu: Asterisk для организации внутренней телефонии - планы на будущее.

Внешний сайт будет на платном хостинге.
Вроде ничего не забыл.
Вопросы будут таковы:
– верен ли подход в целом к организации серверов и распределения "обязанностей"?
– насколько оправдан выбор ПО с учетом того, что немного времени на изучение есть? Разумеется расчет идет ещё на большое и доброжелательное сообщество линуксоидов и массу мануалов в сети.
– какие советы можете дать по оборудованию и ПО?

3. Хранение данных
Я вижу, что это будет отдельный RAID-массив в стойку. Засорять лишним серверные диски нет никакого желания.
Собирать будем RAID 10 на SSD (правда тут опять заковырка, мнения в интернете разделились 50/50, что SSD в рейд-массивах не дает преимуществ)
Хранить будем:
1. Установщики основного пользовательского ПО и драйвера. (Как план на будущее - настройка PXE.)
2. Образы конфигураций серверов и файлы конфигураций сетевого оборудования.
3. Бэкапы базы данных и сервисов.
4. Конечные версии рабочих и внутренних документов.
В роли текущего файлообменника будет использоваться уже имеющийся внешний накопитель разбитый на два раздела:
1 текущие файлы. Очищается раз в неделю с переносом файлов во второй раздел.
2 файлы за предыдущую неделю.
Будет дополнительное внешнее хранилище, подключаемое вручную, для ежеквартального переноса данных. Ничто не защищает данные лучше, чем записать их на диск и физически отключить его. Основной вопрос в рациональности использования SSD и его бюджетность.

4. АТС - дело "десятое", после первых трёх.
Здесь пока полный ноль в знаниях, кроме существования Asterisk.
Что нужно из оборудования для сохранения всех внешних номеррв, да ещё и наладить внутреннюю IP-телефонию?
Есть вариант отдать управление АТС поставщику связи, но хотелось бы своих шишек набить по настройке.

5. Бесперебойность
Хороший бесперебойник. Хотелось чтобы все оборудование выше он держал хотя бы минут 30-60. Т.к. выбор зависит от нагрузки и заложенного резерва (~30%), то сначала определюсь с первыми тремя пунктами, потом перейду к ИБП. Ясно одно: однофазный и с SNMP и датчики температуры/влажности. Хочется иметь возможность получать на телефон сообщение об отключении электроэнергии и аварийно выключить всё с того же телефона, либо по датчикам дать команду серверам на завершение работы.

На этом в принципе всё. Потом тихонечко можно будет обустраивать организацию МФУ-шками всякими. Попутно заняться уже непосредственно автоматизацией, с этим у меня дела обстоят намного лучше. И так же разбираться с зоопарком ПК

Оставшиеся вопросы:
1. Стоить ли заморачиваться с программными рейдами на виртуалках, если их образы будут храниться на внешнем рейде?
2. На какой серверов лучше установить почтовый сервер? Запустить ещё одну виртуалку?
Знаю одно - лимитированные по объему ящики, очищающиеся раз в месяц.
3. Потянут ли стоечные системы охлаждения всё это оборудование?
4. Я знаю что например у Cisco есть симулятор сети, где можно нарисовать схему и настроить её, причем уверен что настройки можно будет экспортировать на рабочее оборудование. Вопрос можно ли подобные симуляторы завязать с виртуальными машинами? Или слишком многого хочу? Есть ли вообще инструментарий для подобного проектирования ИТ-инфраструктуры с возможностью её развернуть в бою?
5. Что мог упустить из виду в этом наброске плана?
  • Вопрос задан
  • 1698 просмотров
7 комментариев
Подписаться 16 Средний 7 комментариев
Пригласить эксперта
Ответы на вопрос 8
@rodkud
Вопрос комплексный - делите его на подвопросы, чтоб хотя бы читать можно было. Если инфраструктура - рисуйте хотя бы от руки схему. Попрбуйте микротики - они и л3 могут и вланы и вообще много чего (курсы их тоже полезны вам будут). Мониторинг - важно. План адресации и отдельные сети - голос, данные, транспортные ( управление девайсами). Ну где-то так для начала...
Ответ написан
4 комментария
4 комментария
CityCat4
@CityCat4
//COPY01 EXEC PGM=IEBGENER
Может пора как на пикабу - значок длиннопоста ввести?

Сведение всего плана модернизации к единовременным разумным тратам на оборудование за счет перехода на свободное ПО.

Идея несомненно хорошая. Но... денег-то сколько? Бюджет вполне может быть "резиновый". А может быть и нет.
Ну и очень сильное желание всё сделать по феншую.

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

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

Что за ерунда, простите? Какрй резервный канал через wifi? Два провайдера в передний микротик решают. wifi делается только с контролем маков, с приличных размеров WPA2 ключом и то - если очень нужен. А лучше вообще без него. Слить документы можно тупо фотая их и сливая фотки в гуглодрайв.
Брать разумеется микротик.
Не, если фанат комстроки - можно бу циску. На наге (nag.ru) можно выкупить относительно недорогие бу циски.
2. Сервер

Поскольку я вижу тут одни линуха, то лучше использовать KVM (qemu + libvirt), если конечно одолеете или же Proxmox. Хотя если сервер единственный - можно VmWare - на один сервер она бесплатная, а в 6.7 вроде как HTML-клиента таки допилили.
Правда сразу возникает вопрос - чем, как и куда будете бэкапить? Вопрос отнюдь не праздный :)
3. Хранение данных

Нет понятия "RAID-массив в стойку". В стойку можно поставить устройство - Synology, QNAP или что-нибудь более дорогое и специализированное. RAID-массив - понятие программное.
RAID10 на SSD? У Вас так все хорошо с бюджетом? Тогда я бы рассмотрел покупку лицензий на VmWare для того, чтобы между хостами работала LiveMigration и покупку софта для бэкапа типа Nakivo вместо SSD для RAID10.
Во-первых, RAID не делают на SSD - дорого. RAID10 на SSD - это очень дорого. Для хранения всей этой байды, что Вы предполагаете там деражть достаточно RAID6 хранилище на обычных дисках (плюс один хотспарник). Причем тут достаточно будет полки типа Synology, шарящей доступ в сеть. Кстати, под бэкапы лучше иметь другую полку - держать бэкапы там же где и документы - это...неумно :)
Ничто не защищает данные лучше, чем записать их на диск и физически отключить его
Ничто не защищает данные лучше чем автоматический бэкап. Вы раз сделаете такой финт ушами, два...а потом забудете. А когда в бэкапе возникнет необходимость - он окажется трехмесячной давности :D
Что нужно из оборудования для сохранения всех внешних номеррв, да ещё и наладить внутреннюю IP-телефонию?

Астериск, конечно же. И железка для него. Не виртуалка. Bare-metal. Потому что для приема внешних линий по меди, если таковые есть (обычные городские телефоны) - понадобятся карты FXO. Для установки в офисе обычных телефонов (не IP) - понадобятся карты FXS. Для IP-телефонов не надо ничего :) Если офис крупный и много входящих номеров - можно взять у поставщика телефонии поток PRI (E1) - 15 или 30 ОЦК - это нужна будет отдельная карта потока. Все это легко собирается в линухе.
1. Стоить ли заморачиваться с программными рейдами на виртуалках, если их образы будут храниться на внешнем рейде?

Нет. Это будет лишняя работа для аппаратного контроллера дисков - и все.
2. На какой серверов лучше установить почтовый сервер? Запустить ещё одну виртуалку?

Конечно. А можно даже и не одну - например, как будет работать антиспам?
причем уверен что настройки можно будет экспортировать на рабочее оборудование

На циску - может быть. Хотите морочиться по циске - морочьтесь. Не хотите - стройте ручками.
5. Что мог упустить из виду в этом наброске плана?

VLAN-ы
Привязка маков к портам коммутатора
Прокси
Контроль доступа в тырнет
Ответ написан
Комментировать
Комментировать
athacker
@athacker
1) фольгированная витая пара -- только между этажами. С обязательным заземлением, иначе толку от неё не будет. В остальном можно разводить обычной UTP без экранирования;

2) Коммутаторы должны быть на каждом этаже. Не хватает 16 портов -- ставьте 24-портовые. Не хватает 24-портовых -- ставьте по 48. Но реально жить будет проще, если у вас коммутаторы доступа будут стоять на каждом этаже. Потому что тогда вам можно будет купить менее ёмкие коммутаторы агрегации и поставить их в серверной. Менее ёмкие -- потому что туда не все на свете компы будут сведены, а только коммутаторы доступа. Подключение каждого коммутатора доступа к агрегации -- двумя линками, в ether-channel, для резервирования;

3) Citrix XenServer... Ну такое... Посмотрите на картинку и найдите там XenServer:
Virtualization%20usage%20by%20company%20

4) "SSD в рейд-массивах не дает преимуществ" -- шта? О_о Собирать SSD в RAID10 -- несколько расточительно. Хотя, конечно, если у вас бюджеты не ограничены... Я бы собирал массив так -- как можно бОльшее количество дисков небольшого объёма, которые бы уже собирал в RAID6 или RAID60 (в зависимости от количества дисков и потребных объёмов). Вот шпиндельные диски -- их имеет смысл в RAID10 собирать, т. к. больно медленные. Но подход тот же самый -- диски меньшего объёма, но в большем количестве. В последние годы я постоянно наблюдаю ситуации -- есть до фига объёмов, но не хватает производительности. Обратное -- производительность есть, но мало объёмов, пока не попадалось. Отсюда рекомендация брать диски поменьше, но количеством побольше. Хотя всё зависит от задач, конечно. И от бюджетов.

Да, и "RAID-массив в стойку" не поставить. Поставить можно железку. Какую-то. Промышленную СХД, например. Или самосборное хранилище (считай, обычный сервер, с линукс или FreeBSD на борту, настроенный на отдачу объёмов по какому-то storage-протоколу). Или корзину DAS. Или NAS. Перечислены в порядке предпочтения. Опять-таки, всё зависит от бюджета.

5) ИБП нужно брать с запасом не 50%, а 100% или даже 200%. Потому что когда вы докинете ещё серверов, то ваши 50% будут съедены моментом. Или когда у вас нагрузка поднимется, то тоже начнёте упираться в потолок мощности ИБП. А то, что нагрузка будет расти и сервера придётся добавлять -- это к бабке не ходи. Поэтому брать нужно с большим запасом, не менее 100%. Как вариант -- брать ИБП, к которым можно подключать внешние блоки батарей. Но мощность ИБП всё равно должен иметь с запасом не менее 100%.

6) Датчики влажности, температуры без регистрации и SMS и возможность отправки SMS-сообщений лучше реализовать с помощью устройств типа UniPing server v3/SMS. Датчиков там отдельно можно докупить всеразличных, вплоть до инфракрасных управлялок для кондиционеров в серверной.

7) RAID-ы в виртуалках -- это бред, конечно же. Достаточно обеспечить отказоусточивое дисковое хранилище. Лучше всего с отказоустойчивостью дела обстоят у промышленных СХД, конечно же. HPE MSA, Dell MF -- вот это вот всё.

8) Правила распределения сервисов по виртуалкам очень простое -- один выстрел -- один труп сервис -- одна машина. Т. е. под почтовый сервер -- одна виртуалка. Под DNS -- ещё машина. Даже две. Под контроллеры доменов -- две виртуалки (минимум). Под DHCP -- ещё машина.

XXX) Если заказчик хочет, чтобы всё работало хорошо -- то лучше, конечно, пригласить профессионалов. Потому как судя по вашим вопросам, вы пока ещё таковым не являетесь. Если же он готов терпеть и пожинать плоды экспериментов в течение довольно долгого времени -- тогда конечно.

XXX+1) Да, и про резервное копирование не забудьте. Чем бэкапить, и куда складывать. Hint: складывать на ту же хранилку, на которой виртуалки работают -- моветон и чревато печальными последствиями.
Ответ написан
8 комментариев
8 комментариев
Jump
@Jump Куратор тега Системное администрирование
Системный администратор со стажем.
Если представили эту картину, и да же если вы далеки от подобной сферы, то несомненно пришли в замешательство и поняли что так дальше нельзя
Работает - не трожь!
Если не работает - решай проблемы.
Если руководство поставило задачу привести в порядок - приводи.

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

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

Тут собственно основной вопрос в рациональности использования SSD и его бюджетность.
Цены на гигабайт SSD несложно посмотреть на яндекс маркете и сравнить с ценами на HDD.
И будет понятна его бюджетность.
Объясню - дорого. Заметно дороже HDD.
SDD ставят для активной работы с данными, но никак не для хранения архивов.
А уж если вы собрались хранить при отключенном питании - SSD без питания теряет данные.

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

мнения в интернете разделились 50/50, что SSD в рейд-массивах не дает преимуществ
SSD в любом случае работает шустрее HDD, даже в RAID. Но зачастую не так шустро чем просто SSD. К тому же RAID из SSD нужно уметь правильно готовить.

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

Сведение всего плана модернизации к единовременным разумным тратам на оборудование за счет перехода на свободное ПО.
Разумно это не единовременные траты, а постепенная замена оборудования. И непонятно какое отношение переход на свободное ПО имеет к тратам на оборудование.

Ну и очень сильное желание всё сделать по феншую.
Нет никакого феншуя!
Есть требования диктуемые бизнесом.
Ответ написан
14 комментариев
14 комментариев
@d-stream
Готовые решения - не подаю, но...
Тут встает выбор:
1. Или на каждый этаж заводить управляемый коммутатор из дешевого сегмента (D-Link какой-нибудь на 16-24 портов), что не особо нравится в плане расширения, поэтому склоняюсь к второму варианту;
2. Разориться на парочку многопортовых стоечных коммутаторов и вести к каждой машине свой кабель.
На сколько нарыл в интернете можно взять два по 48 портов и объединить их.
Помимо пользовательских ПК, будут сетевые МФУ, возможно ещё камеры, ip-телефония и т.д.


Истина лежит где-то посередине. 1. Все коммутаторы должны быть управляемыми (про vlan уже написано), 2. "центр" и "доступ" - тут скорее по геометрии-протяженности смотреть надо - не факт что от коммутатора в серверной до какого-нибудь кабинета будет гарантировано меньше 90м кабеля...

Ну и в любом случае нормальный феншуй - "ядерные" коммутаторы желательны с повышенным интеллектом. Например умеющие ограничено маршрутизировать на скорости коммутации (так называемы L3 коммутаторы). Ну и быстрые. А уже юзерская часть - коммутаторы L2 попроще, подешевле и например 100мбит с гибабитными аплинками.

Хороший бесперебойник. Хотелось чтобы все оборудование выше он держал хотя бы минут 30-60. Т.к. выбор зависит от нагрузки и заложенного резерва (~30%),
В общем-то обычно бесперебойное питание на UPS ориентируется на 5-10-15 минут, а остальное время - резервные вводы, ДГУ и т.п.

Притом это не мода, а просто рациональность - ибо ДГУ + 10-минутный UPS - зачастую заметно дешевле 2-часового UPS.
Ответ написан
Комментировать
Комментировать
saboteur_kiev
@saboteur_kiev Куратор тега Компьютерные сети
software engineer
На что установлен ориентир:
В первую очередь разумеется стабильная работа с отказоустойчивой системой.

Берем нормальную стойку для серверного и сетевого оборудованием.

Можно легко поискать бушную.

1. Сеть
В первую очередь хотелось бы перекроить в нормальные короба с выводом розеток, а не набивать провода в тонкие кабель-каналы.

Какая разница в чем идут кабеля? Главное чтобы они шли не в одном канале с силовыми и их было достаточно.

Кабель выберем экранированную витую пару.

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

Тут встает выбор:
1. Или на каждый этаж заводить управляемый коммутатор из дешевого сегмента (D-Link какой-нибудь на 16-24 портов), что не особо нравится в плане расширения. Поэтому склоняюсь к второму варианту.

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

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

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

Дальше, т.к. в наличии есть филиалы, то не обойтись без маршрутизатора.

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

Он в дальнейшем поможет организовать и активный резервный канал связи, соответственно 2 WAN порта + wifi модуль.
WiFi будет для пользовательский мобильных устройств через резервный канал, т.к. основной канал планируется резать от "паразитного" трафика - только рабочие ресурсы.

Vlan

2. Сервер
Тут меня одолевают смутные сомнения, взять 2 сервера и объединить их в кластер для оперативной подмены или
в целях экономии взять 1 сервер и считать что ничего с ним не случиться.
Хотелка для серверов: недорогая стоечная kvm консоль с IP.

Говоря "сервер" нужно сразу говорить сервер чего. Что он будет делать.
Кластер нужен если простой стоит гораздо дороже, чем поднять из бэкапа. А сейчас поднять виртуалку из бэкапа - дело очень быстрое.

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

1 виртуальный сервер - Linux Ubuntu: Работает как DHCP-сервер (? или лучше отдать роль коммутатору/маршрутизатору) + как домен контроллер и служба каталогов (LDAP. Беглый анализ показал что популярности Samba) + сервер лицензий.

Нагрузка на домен контроллер, DHCP и ldap обычно такая маленькая, что совершенно нет смысла делать для этого кластер. Обычная виртуалка на виртуалбокс справится с офисом на пару сот рабочих мест. А учитвая, что новые юзеры/новые машины в домен заводятся нечасто, бэкап недельной давности может оказаться вполне актуальным. Поэтому вместо кластера - просто каждую ночь резервная копия всей виртуалки на другой физический комп, и в случае чего просто поднимаете виртуалку с домен контроллером на другом сервере за пару минут. Сразу минус все сложности с кластерами.

2 виртуальный сервер: ОС будет зависеть если все таки отыщется лицензия на MS SQL и Windows Server. Если нет, то ставим Linux Ubuntu и отдаем сервер под базу данных на PostgreSQL. Приоритет ресурсов: память.

А зачем вам база, если так легко переезжаете с одной на другую? Если вам непринципиально, то сразу PostreSQL берите, зачем с лицензиями мучаться и виндой?

3. Хранение данных

Серьезно? SSD, точнее РЕЙД из SSD для хранения драйверов инсталляшек и бэкапов?
SSD нужно разве что под postgres или 1C и без всяких рейдов, все остальное - на обычные HDD.
Бэкапы настраивать исходя из предположительных потерь в случае простоя.

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

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

5. Что мог упустить из виду в этом наброске плана?

Наймите в вашем городе сисадмина или компанию, которая настроит или разработает для вас детальный план, и будет консультировать первые пару месяцев.
Ответ написан
9 комментариев
9 комментариев
@ashv24
Из какого города автор? А то есть бу оборудование, шкаф на 15 юнитов кабеус и башенный корпус серверный большой большой...
Ответ написан
4 комментария
4 комментария
@BAF285
Самое главное сделать кластер DHCP серверов для распределения нагрузки и резервирования
https://bafista.ru/otkazoustojchivyj-dhcp-klaster/
Ответ написан
Комментировать
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
Вакансии с Хабр Карьеры
Преподаватель по нейросетям
CODDY
от 25 000 до 45 000 ₽
Младший аналитик
Сбер • Москва
от 130 000 ₽
Аналитик 1С
SM Lab
от 200 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Разработать телеграм бота с реферальной системой, Юкассой и ChatGPT
23 дек. 2024, в 02:13
20000 руб./за проект
Собрать из исходного кода и запустить в докере рабочее приложение с бд
22 дек. 2024, в 22:57
500 руб./за проект
Аппликация для фильтра заказов
22 дек. 2024, в 20:40
10000 руб./за проект
Ещё заказы