Я пытаюсь изучить сеть центра обработки данных, и мне трудно понять передовой опыт по назначению IP-адресов и VLAN серверам и стойкам.
Что касается моего вопроса, я предполагаю, что это типичная трехуровневая сеть с коммутаторами Top of the Rack (TOR), действующими в качестве коммутаторов доступа. Я хочу понять, что я бы рассмотрел при назначении IP-адресов и виртуальных локальных сетей серверам в стойках (и между стойками). Предположим, IP-адреса назначаются статически. Далее, допустим, 10 стоек по 40 серверов в каждой (всего 400 серверов).
Я понимаю, что существует миллион способов спроектировать сеть, но на самом деле я просто ищу лучшие практики (или указатели на них).
Один из способов назначить IP-адреса - назначить одну большую подсеть (/ 16 или / 24 в зависимости от количества хостов) всему центру обработки данных. Затем я мог бы последовательно подключить ToR к магистралям VLAN. Из того, что я прочитал, я мог создавать VLAN типа Management, vMotion / live Migration, данные приложений. Однако для этого потребуется, чтобы на сервере было 3 сетевых адаптера?
Второй способ, который я мог придумать, - это последовательно назначать IP-адреса 1-400 серверам, но НЕ подключать TOR напрямую (а подключать их через маршрутизатор). Я не понимаю, какого поведения это могло бы быть. Все серверы будут в одной подсети, поскольку у них одинаковый сетевой идентификатор. Однако, поскольку коммутаторы подключаются только через маршрутизаторы, будут ли все эти серверы находиться в одном домене L2?
Третий способ - назначить подсеть для каждой стойки, но это приведет к потере много IP-пространства.
Какие-либо рекомендации о том, какой путь является лучшей практикой? Кроме того, каким образом я должен думать об использовании виртуальных локальных сетей вместе с подсетями?
Не исчерпывающий ответ, но есть о чем подумать:
Преимущество виртуальных локальных сетей заключается в том, что сетевая карта может одновременно обращаться к нескольким подсетям, поэтому в небольшой или не очень загруженной среде может оказаться ненужным назначать несколько физических восходящих каналов. С другой стороны, для всех случаев использования, где вы можете увидеть конфликт трафика (хранилище, vMotion, данные виртуальных машин), вам, скорее всего, потребуется разделить типы трафика между физическими интерфейсами.
Конечно, вы захотите, чтобы каждое соединение обеспечивало достаточную избыточность, а это значит, что вам нужно как минимум два физических интерфейса на каждый требуемый восходящий канал.
Что касается статических и динамических IP-адресов, вообще говоря, когда вы имеете дело с более чем несколькими хостами, вам нужно свести к минимуму ручную работу, как из-за накладных расходов на управление, так и для ограничения риска человеческой ошибки. Используйте резервирование DHCP, если вам нужно, чтобы у машин были предсказуемые адреса. Объедините DHCP с динамическим DNS, чтобы упростить обратный поиск.
Если вы ожидаете значительного трафика между стойками, вы можете столкнуться с узкими местами, если вам нужно направить его через центральную точку. Виртуализация сети с использованием, например, VMware NSX может помочь вам разгрузить значительные блоки трафика виртуальных машин с маршрутизатора на хосты виртуальных машин, если они имеют общее L2-соединение друг с другом.
Если у вас «всего» несколько стоек, я бы не стал беспокоиться о потере подсети / 24 IPv4 на стойку для сетей управления: лучше перестраховаться, чем сожалеть, если у вас когда-нибудь возникнет необходимость в увеличении физической плотности серверов.