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

Правильное размещение устройств на фабрике Fibre Channel

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

Два наших центра обработки данных находятся на расстоянии около 3,2 км друг от друга по мере прохождения волокна. Мы уже пару лет получаем надежный сервис 4Gb, и я очень надеюсь, что он сможет поддерживать и 8Gb.

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

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

Вот схема того, что я думаю о планировке. Синие элементы - новые, красные - существующие ссылки, которые будут (повторно) перемещены.


(источник: sysadmin1138.net)

Линия с красной стрелкой - это текущее соединение коммутатора ISL, оба ISL исходят от одного и того же коммутатора. EVA6100 в настоящее время подключен к обоим коммутаторам 16/4, имеющим ISL. Новые коммутаторы позволят нам иметь два коммутатора в удаленном DC, некоторые из ISL дальнего действия перемещаются на новый коммутатор.

Преимущество этого заключается в том, что каждый коммутатор находится не более чем в 2 переходах от другого коммутатора, а два EVA4400, которые будут находиться в отношении репликации EVA, находятся на расстоянии 1 перехода друг от друга. EVA6100 в таблице - более старое устройство, которое в конечном итоге будет заменено, возможно, еще одним EVA4400.

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

На данный момент кластер ESX может выдержать отключение до 3, может быть, 4 хостов, прежде чем мы должны начать отключение виртуальных машин для освобождения места. К счастью, все включено MPIO.

Текущие каналы ISL 4 Гб не приблизились к насыщению, которое я заметил. Это может измениться с репликацией двух EVA4400, но по крайней мере один из ISL будет иметь размер 8 Гбит. Глядя на производительность, которую я получаю от EVA4400-A, я очень уверен, что даже с трафиком репликации нам будет сложно пересечь линию 4Gb.

Кластер обслуживания файлов с 4 узлами может иметь два узла на SAN1SW4 и два на SAN1SW1, так как это поместит оба массива хранения в один переход.

Я немного ломаю голову над 10 узлами ESX. Три на SAN1SW4, три на SAN1SW2 и четыре на SAN1SW1 - это вариант, и мне было бы очень интересно услышать другие мнения о компоновке. У большинства из них есть двухпортовые карты FC, поэтому я могу дважды запустить несколько узлов. Не все из них, но достаточно, чтобы позволить одному переключателю выйти из строя, не убивая все.

Два блока MS-SQL должны быть подключены к SAN1SW3 и SAN1SW2, поскольку они должны быть рядом с их основным хранилищем, а производительность экспорта базы данных менее важна.

Диски LTO4 в настоящее время находятся на SW2 и 2 переходах от их основного стримера, поэтому я уже знаю, как это работает. Они могут оставаться на SW2 и SW3.

Я бы предпочел не делать нижнюю половину диаграммы полностью подключенной топологией, поскольку это уменьшит количество используемых нами портов с 66 до 62, а SAN1SW1 составит 25% ISL. Но если это настоятельно рекомендуется, я могу пойти по этому пути.

Обновление: некоторые показатели производительности, которые, вероятно, будут полезны. У меня они были, я просто расставил, что они полезны для такого рода задач.

EVA4400-A на приведенном выше графике выполняет следующие функции:

EVA6100 намного более загружен, поскольку он является домом для кластера ESX, MSSQL и всей среды Exchange 2007.

Буду признателен за любые ваши предложения.

Извините за задержку.

Посмотрел, что у вас есть и чего вы хотите достичь, у меня было несколько мыслей, сначала вот красивая картинка ...

  • Похоже, что сейчас нет смысла использовать канал 8 Гбит / с между сайтами - причина в том, что вы ограничены портами 4 Гбит / с на удаленном 4400, у вас уже есть стабильный 4 Гбит / с, плюс доступная пропускная способность намного выше, чем фактическое требование к использованию - Сегодня просто бесполезно ставить туда один из переключателей 24x8. Я бы использовал два коммутатора 16x4Gb на удаленном сайте.
  • У меня возникнет соблазн использовать новые коммутаторы 24x8 в качестве основных коммутаторов - большая часть вашего трафика идет от сервера к 6100, и новый коммутатор будет намного быстрее. Таким образом, вы должны увидеть небольшой прирост производительности, так как новый коммутатор имеет большие буферы и меньшую задержку, а также вы можете выбрать, какие серверы переместить на 8 ГБ, когда захотите, то же самое, когда вы меняете 6100 ( У 4600 есть собственные порты 8Gb, но это еще не официально;)).
  • Затем мы переходим к той части дизайна, где у нас есть два варианта; оставить или отказаться от двух «средних коммутаторов» 16x4 Гбайт - исключительно на основе количества портов. В основном, если вы использовали коммутаторы 24x8 в качестве базовых блоков, у вас есть только 3 запасных порта (так как вы будете использовать 18 для 18 серверов, плюс 2 для 6100 и канал ISL, что равно 21 используемому). Вы мог подключите локальный 4400 к коммутаторам 24x8, оставив ровно 1 порт для ваших ленточных накопителей, но при этом останется ноль свободных портов. У меня возникнет соблазн использовать два «средних коммутатора» 16x4 Гб либо в качестве вторичных локальных коммутаторов для обработки локальных 4400 и ленточных накопителей, либо, возможно, для обработки межсайтовых каналов ISL, если вы захотите - хотя у вас будут порты. бесплатно на коммутаторах 24x8Gb, чтобы сделать это прямо оттуда, если хотите - я не показывал оба, поскольку они действительно очень похожи.

Таковы мои мысли - есть некоторые хитрости, но мои общие идеи есть - не стесняйтесь возвращаться ко мне с любыми разъяснениями.