V předchozích dvou dílech (, ) jsme se podívali na principy, na kterých byla postavena nová zakázková továrna, a mluvili o migraci všech pracovních míst. Nyní je čas mluvit o továrně na servery.
Dříve jsme neměli žádnou samostatnou serverovou infrastrukturu: serverové přepínače byly připojeny ke stejnému jádru jako uživatelské distribuční přepínače. Řízení přístupu bylo prováděno pomocí virtuálních sítí (VLAN), směrování VLAN bylo prováděno v jednom bodě - na jádře (podle principu ).
Stará síťová infrastruktura
Současně s novou kancelářskou sítí jsme se rozhodli vybudovat novou serverovnu a pro ni samostatnou novou továrnu. Ukázalo se, že je to malé (tři serverové skříně), ale v souladu se všemi kánony: samostatné jádro na přepínačích CE8850, plně síťovaná (spine-leaf) topologie, přepínače CE6870 v horní části stojanu (ToR), samostatný pár přepínačů pro propojení se zbytkem sítě (hraniční listy). Zkrátka kompletní mleté maso.
Síť nové továrny na servery
Rozhodli jsme se opustit server SCS ve prospěch připojení serverů přímo k přepínačům ToR. Proč? Již máme dvě serverové místnosti, které jsou postaveny pomocí serveru SCS, a uvědomili jsme si, že toto je:
- nepohodlné použití (mnoho opětovného připojení, musíte pečlivě aktualizovat kabelový protokol);
- drahé z hlediska prostoru obsazeného patch panely;
- je překážkou, když je potřeba zvýšit rychlost připojení serverů (např. přejít z 1 Gbit/s připojení přes měď na 10 Gbit/s přes optické).
Při přesunu do nové serverové továrny jsme se pokusili upustit od připojování serverů rychlostí 1 Gbit/s a omezili jsme se na 10 Gbit rozhraní. Téměř všechny staré servery, které to neuměly, byly virtualizovány a zbytek byl připojen přes gigabitové transceivery na 10 gigabitové porty. Spočítali jsme si to a rozhodli jsme se, že to bude levnější, než pro ně instalovat samostatné gigabitové přepínače.
ToR přepínače
Také v naší nové serverovně jsme nainstalovali samostatné přepínače pro správu mimo pásmo (OOM) s 24 porty, jeden na stojan. Tento nápad se ukázal jako velmi dobrý, ale nebylo dost portů, příště nainstalujeme OOM switche se 48 porty.
Do sítě OOM připojujeme rozhraní pro vzdálenou správu serverů jako je iLO nebo iBMC v terminologii Huawei. Pokud server ztratil hlavní připojení k síti, bude možné se k němu dostat přes toto rozhraní. K OOM spínačům jsou také připojena ovládací rozhraní ToR spínačů, teplotních čidel, řídicích rozhraní UPS a dalších podobných zařízení. Síť OOM je přístupná přes samostatné rozhraní firewallu.
Síťové připojení OOM
Párování serverových a uživatelských sítí
V zakázkové továrně se samostatné VRF používají pro různé účely – pro připojení uživatelských pracovních stanic, video monitorovacích systémů, multimediálních systémů v zasedacích místnostech, pro organizaci stánků a ukázkových ploch atd.
V továrně serveru byla vytvořena další sada VRF:
- Pro připojení běžných serverů, na kterých jsou nasazeny podnikové služby.
- Samostatný VRF, v rámci kterého jsou nasazeny servery s přístupem z internetu.
- Samostatný VRF pro databázové servery, ke kterým přistupují pouze jiné servery (například aplikační servery).
- Samostatné VRF pro náš poštovní systém (MS Exchange + Skype pro firmy).
Máme tedy sadu VRF na straně továrny uživatele a sadu VRF na straně továrny serveru. Obě sady jsou nainstalovány na clusterech podnikové brány firewall (FW). ME jsou připojeny k hraničním přepínačům (hraničním listům) jak serverové, tak uživatelské struktury.
Propojení továren prostřednictvím ME - fyzika
Propojení továren přes ME - logika
Jak migrace probíhala?
Během migrace jsme propojili nové a staré serverové továrny na úrovni datového spoje prostřednictvím dočasných trunků. Pro migraci serverů umístěných v konkrétní VLAN jsme vytvořili samostatnou přemosťovací doménu, která zahrnovala VLAN staré serverové továrny a VXLAN nové serverové továrny.
Konfigurace vypadá asi takto, klíčové jsou poslední dva řádky:
bridge-domain 22
vxlan vni 600022
evpn
route-distinguisher 10.xxx.xxx.xxx:60022
vpn-target 6xxxx:60022 export-extcommunity
vpn-target 6xxxx:60022 import-extcommunity
interface Eth-Trunk1
mode lacp-static
dfs-group 1 m-lag 1
interface Eth-Trunk1.1022 mode l2
encapsulation dot1q vid 22
bridge-domain 22
Migrace virtuálních strojů
Poté pomocí VMware vMotion byly virtuální stroje v této VLAN migrovány ze starých hypervizorů (verze 5.5) na nové (verze 6.5). Současně došlo k virtualizaci hardwarových serverů.
Až to zkusíte znovuNakonfigurujte MTU předem a zkontrolujte průchod velkých paketů „end to end“.
Ve staré serverové síti jsme používali virtuální firewall VMware vShield. Vzhledem k tomu, že VMware již tento nástroj nepodporuje, přešli jsme z vShield na hardwarové firewally současně s migrací na novou virtuální farmu.
Poté, co v konkrétní VLAN na staré síti nezůstaly žádné servery, přepnuli jsme směrování. Dříve se to provádělo na starém jádru postaveném pomocí technologie Collapsed Backbone a v nové továrně na servery jsme používali technologii Anycast Gateway.
Přepínání směrování
Po přepnutí směrování pro konkrétní VLAN byla odpojena od domény mostu a vyloučena z trunku mezi starou a novou sítí, tj. zcela se přesunula do nové serverové továrny. Takto jsme migrovali asi 20 VLAN.
Vytvořili jsme tedy novou síť, nový server a novou virtualizační farmu. V jednom z následujících článků si povíme, co jsme dělali s Wi-Fi.
Maxim Klochkov
Senior konzultant skupiny síťového auditu a komplexních projektů
Centrum síťových řešení
"Jet Infosystems"
Zdroj: www.habr.com