Dostajemy parę nowych przełączników 8 Gb dla naszej sieci kanałów światłowodowych. Jest to dobra rzecz, ponieważ brakuje nam portów w naszym głównym centrum danych i pozwoli nam mieć co najmniej jeden ISL 8 Gb między naszymi dwoma centrami danych.
Nasze dwa centra danych znajdują się w odległości około 3,2 km od siebie, gdy biegnie światłowód. Od kilku lat otrzymujemy solidną usługę 4 Gb i mam nadzieję, że może ona również utrzymać 8 Gb.
Obecnie zastanawiam się, jak zmienić konfigurację naszej sieci, aby akceptowała te nowe przełączniki. Z powodu decyzji o kosztach kilka lat temu nie prowadzimy całkowicie oddzielnej tkaniny z podwójną pętlą. Koszt pełnej redundancji był postrzegany jako droższy niż mało prawdopodobne przestoje awarii przełącznika. Ta decyzja została podjęta przed moim czasem i od tego czasu niewiele się poprawiło.
Chciałbym skorzystać z okazji, aby uczynić naszą tkaninę bardziej odporną na awarię przełącznika (lub aktualizacji FabricOS).
Oto schemat tego, co myślę o układzie. Niebieskie elementy są nowe, czerwone elementy to istniejące linki, które zostaną (ponownie) przeniesione.
(źródło: sysadmin1138.net )
Czerwona linia ze strzałkami to bieżące łącze przełącznika ISL, oba numery ISL pochodzą z tego samego przełącznika. EVA6100 jest obecnie podłączony do obu przełączników 16/4, które mają ISL. Nowe przełączniki pozwolą nam mieć dwa przełączniki w zdalnym DC, jeden z ISL dalekiego zasięgu przenosi się do nowego przełącznika.
Zaletą tego jest to, że każdy przełącznik ma nie więcej niż 2 przeskoki od innego przełącznika, a dwa EVA4400, które będą w relacji replikacji EVA, są oddalone od siebie o 1 przeskok. EVA6100 na wykresie to starsze urządzenie, które ostatecznie zostanie wymienione, prawdopodobnie na jeszcze jedną EVA4400.
Dolna połowa wykresu to miejsce, w którym znajduje się większość naszych serwerów, i mam obawy dotyczące dokładnego umiejscowienia. Co trzeba tam wejść:
- 10 hostów VMWare ESX4.1
- Dostęp do zasobów w EVA6100
- 4 serwery Windows Server 2008 w jednym klastrze przełączania awaryjnego (klaster serwer plików)
- Dostęp do zasobów zarówno w EVA6100, jak i zdalnym EVA4400
- 2 serwery Windows Server 2008 w drugim klastrze przełączania awaryjnego (zawartość tablicy)
- Dostęp do zasobów w EVA6100
- 2 serwery baz danych MS-SQL
- Dostęp do zasobów w EVA6100, z nocnym eksportem DB do EVA4400
- 1 biblioteka taśm LTO4 z 2 napędami taśm LTO4. Każdy dysk ma własny port światłowodowy.
- Serwery kopii zapasowych (nie na tej liście) buforują je
W tej chwili klaster ESX może tolerować do 3, a może 4 hostów, które przestają działać, zanim będziemy musieli zacząć wyłączać maszyny wirtualne z powodu miejsca. Na szczęście wszystko ma włączone MPIO.
Obecne linki 4Gb ISL nie zbliżyły się do nasycenia, które zauważyłem. To może się zmienić wraz z replikacją dwóch EVA4400, ale co najmniej jeden z ISL będzie miał 8 Gb. Patrząc na wydajność, z której wychodzę z EVA4400-A, jestem bardzo pewien, że nawet przy ruchu replikacyjnym trudno będzie nam przekroczyć linię 4 Gb.
4-węzłowy klaster obsługujący pliki może mieć dwa węzły na SAN1SW4 i dwa na SAN1SW1, ponieważ to spowoduje odłożenie obu macierzy pamięci o jeden skok.
10 węzłów ESX, nad którymi jestem nieco chory. Trzy na SAN1SW4, trzy na SAN1SW2 i cztery na SAN1SW1 to opcja, i bardzo chciałbym usłyszeć inne opinie na temat układu. Większość z nich ma karty FC z podwójnym portem, więc mogę dwukrotnie uruchomić kilka węzłów. Nie wszystkie z nich , ale wystarczające, aby pozwolić jednemu przełącznikowi zawieść bez zabicia wszystkiego.
Dwie skrzynki MS-SQL muszą działać na SAN1SW3 i SAN1SW2, ponieważ muszą znajdować się blisko podstawowej pamięci, a wydajność eksportu db jest mniej ważna.
Dyski LTO4 są obecnie na SW2 i 2 przeskokach od głównego streamera, więc już wiem, jak to działa. Mogą pozostać na SW2 i SW3.
Wolałbym, aby dolna połowa wykresu nie była w pełni połączoną topologią, ponieważ zmniejszyłoby to naszą użyteczną liczbę portów z 66 do 62, a SAN1SW1 wynosiłby 25% ISL. Ale jeśli jest to zdecydowanie zalecane, mogę wybrać tę trasę.
Aktualizacja: Niektóre numery wydajności, które prawdopodobnie będą przydatne. Miałem je, właśnie rozłożyłem, że są przydatne w tego rodzaju problemach.
EVA4400-A na powyższej tabeli wykonuje następujące czynności:
- Podczas dnia pracy:
- Średnia liczba operacji we / wy poniżej 1000 z skokami do 4500 podczas migawek ShadowCopy klastra serwerów plików (trwa około 15-30 sekund).
- MB / s zazwyczaj utrzymuje się w zakresie 10-30 MB, z skokami do 70 MB i 200 MB podczas ShadowCopies.
- W nocy (kopie zapasowe) następuje naprawdę szybkie pedałowanie:
- Operacje we / wy wynoszą średnio około 1500, z skokami do 5500 podczas tworzenia kopii zapasowych DB.
- MB / s różni się bardzo, ale działa około 100 MB przez kilka godzin i pompuje imponujące 300 MB / s przez około 15 minut podczas procesu eksportu SQL.
EVA6100 jest znacznie bardziej zajęty, ponieważ jest domem dla klastra ESX, MSSQL i całego środowiska Exchange 2007.
- W ciągu dnia operacje we / wy wynoszą średnio około 2000 z częstymi skokami do około 5000 (więcej procesów bazy danych), a MB / s średnio od 20-50 MB / s. Maksymalne MB / s zdarza się podczas migawek ShadowCopy w klastrze obsługującym pliki (~ 240 MB / s) i trwa krócej niż minutę.
- W nocy Exchange Online Defrag, który działa od 1 do 5 rano, pompuje operacje we / wy do linii na 7800 (blisko prędkości flanki dla losowego dostępu z tą liczbą wrzecion) i 70 MB / s.
Byłbym wdzięczny za wszelkie sugestie.
