Ми отримуємо пару нових 8Gb комутаторів для нашої тканини волоконних каналів. Це гарна річ, оскільки у нас в основному центрі обробки даних закінчено порти, і це дозволить нам принаймні один ISL 8Gb працювати між двома нашими центрами обробки даних.
Наші два центри обробки даних розташовані приблизно на відстані 3,2 км, коли працює волокно. Ми отримуємо надійний сервіс 4Gb вже пару років, і я сподіваюся, що він також може підтримувати 8Gb.
Зараз я розгадую, як перенастроїти нашу тканину, щоб прийняти ці нові перемикачі. Завдяки рішенням про витрати кілька років тому ми не працюємо з повністю окремою тканиною з подвійною петлею. Вартість повної надмірності вважалася дорожчою, ніж малоймовірний час простою виходу з комутатора. Це рішення було прийняте до мого часу, і з тих пір все не покращилося.
Я хотів би скористатися цією можливістю, щоб наша тканина стала більш стійкою внаслідок відмови комутатора (або оновлення FabricOS).
Ось схема того, що я думаю для планування. Сині елементи - це нові, червоні - це існуючі посилання, які будуть (пере) переміщені.
(джерело: sysadmin1138.net )
Червона стрілка - це поточне посилання ISL комутатора, обидва ISL походять від одного комутатора. В даний час EVA6100 підключений до обох 16/4 комутаторів, які мають ISL. Нові комутатори дозволять нам мати два вимикачі у віддаленому постійному струмі, а один із далекобійних ISL переходить до нового вимикача.
Перевагою цього є те, що кожен перемикач має не більше 2 переходів від іншого перемикача, а два EVA4400, які знаходяться у співвідношенні реплікації EVA, знаходяться в одному скаку один від одного. EVA6100 на графіку - це старший пристрій, який згодом буде замінений, ймовірно, ще одним EVA4400.
У нижній половині діаграми знаходиться більшість наших серверів, і я маю певні занепокоєння щодо точного розміщення. Що потрібно туди зайти:
- 10 хостів VMWare ESX4.1
- Доступ до ресурсів на EVA6100
- 4 сервери Windows Server 2008 в одному кластері, що перебуває у відмові (кластер файлових серверів)
- Доступ до ресурсів як на EVA6100, так і на віддалений EVA4400
- 2 сервери Windows Server 2008 у другому кластері відключення (вміст дошки)
- Доступ до ресурсів на EVA6100
- 2 сервери баз даних MS-SQL
- Доступ до ресурсів на EVA6100, а нічний експорт БД переходить до EVA4400
- 1 бібліотека стрічок LTO4 з 2 стрічковими накопичувачами LTO4. Кожен привід отримує власний волоконний порт.
- Резервні сервери (яких немає в цьому списку) намотують їх
На даний момент кластер ESX може терпіти до 3, а може і 4, хостів, що виходять з ладу, перш ніж нам потрібно починати вимикати VM для простору. На щастя, все увімкнуло MPIO.
Поточні посилання ISL 4Gb не наблизилися до насичення, яке я помітив. Це може змінитися з реплікацією двох EVA4400, але принаймні один із ISL буде 8Gb. Дивлячись на продуктивність, яку я виходжу з EVA4400-A, я дуже впевнений, що навіть при трафіку реплікації нам буде важко перетинати лінію 4Gb.
4-вузловий кластер, що обслуговує файли, може мати два вузли на SAN1SW4 та два на SAN1SW1, оскільки це дозволить поставити обидва масиви зберігання за один скачок.
10 вузлів ESX, які я дещо з головою дряпаю. Три на SAN1SW4, три на SAN1SW2 і чотири на SAN1SW1 - це варіант, і мені буде дуже цікаво почути інші думки щодо верстки. Більшість із них мають картки FC з двома портами, тому я можу подвоїти кілька вузлів. Не всі з них , але достатньо, щоб один вимикач вийшов з ладу, не вбивши все.
Дві скриньки MS-SQL повинні працювати на SAN1SW3 та SAN1SW2, оскільки вони повинні бути близькими до їх первинного зберігання, а ефективність експорту db менш важлива.
Зараз накопичувачі 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 Мб протягом декількох годин, і під час процесу експорту SQL перекачує вражаючі 300 Мб / с протягом 15 хвилин.
EVA6100 набагато більш зайнятий, оскільки він є домом для кластера ESX, MSSQL та цілого середовища Exchange 2007.
- Протягом дня Ops Ops в середньому становить близько 2000 з частими скачками до приблизно 5000 (більше процесів в базі даних), і МБ / с в середньому між 20-50 МБ / с. Пік MB / s відбувається під час знімків ShadowCopy на кластер-сервісі файлів (~ 240 МБ / с) і триває менше хвилини.
- Вночі Exchange Online Defrag, який працює з 1 ранку до 5 ранку, перекачує введення / виведення Ops до лінії зі швидкістю 7800 (близька до флангової швидкості для випадкового доступу з цією кількістю шпинделів) і 70 Мб / с.
Буду вдячний за всі ваші пропозиції.
