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

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

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

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

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

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

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

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

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

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

• 10 хостов VMWare ESX4.1
  • Доступ к ресурсам на EVA6100
• 4 сервера Windows Server 2008 в одном отказоустойчивом кластере (кластер файловых серверов)
  • Доступ к ресурсам как на EVA6100, так и на удаленном EVA4400
• 2 сервера Windows Server 2008 во втором отказоустойчивом кластере (содержимое Blackboard)
  • Доступ к ресурсам на EVA6100
• 2 сервера баз данных MS-SQL
  • Получает доступ к ресурсам на EVA6100, а ночные экспорты БД идут на EVA4400
• 1 ленточная библиотека LTO4 с 2 ленточными накопителями LTO4. Каждый диск получает свой собственный оптоволоконный порт.
  • Резервные серверы (не в этом списке) спулинговать к ним

В настоящее время кластер ESX может выдержать до 3, может быть, 4 хостов, отключающихся до того, как мы начнем выключать виртуальные машины из-за недостатка места. К счастью, у MPIO все включено.

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

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

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

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

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

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

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

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

• В течение рабочего дня:
  • Операции ввода-вывода в среднем составляют менее 1000 с скачками до 4500 во время снимков кластера файлового сервера ShadowCopy (длятся около 15-30 секунд).
  • МБ / с обычно остается в диапазоне 10-30 МБ, с пиками до 70 МБ и 200 МБ во время ShadowCopies.
• Ночью (резервное копирование) происходит, когда он действительно крутится быстро:
  • Количество операций ввода-вывода в среднем составляет около 1500, а при резервном копировании БД - до 5500.
  • МБ / с сильно варьируется, но работает около 100 МБ в течение нескольких часов и обеспечивает впечатляющие 300 МБ / с в течение 15 минут в процессе экспорта SQL.

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

• В течение дня количество операций ввода-вывода в среднем составляет около 2000 с частыми скачками до 5000 (больше процессов базы данных), а МБ / с в среднем между 20-50 МБ / с. Пик МБ / с происходит во время моментальных снимков ShadowCopy в кластере, обслуживающем файлы (~ 240 МБ / с), и длится менее минуты.
• Ночью дефрагментация Exchange Online, которая выполняется с 1:00 до 5:00, подкачивает операции ввода-вывода на линию со скоростью 7800 (близкой к боковой скорости для произвольного доступа с таким количеством шпинделей) и 70 МБ / с.

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

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

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

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

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