Migrujeme Sun DS na 389 Directory server
Stojíte-li před podobným úkolem, najdete v tomto článku pár informací jak jsme my řešili migraci pro našeho zákazníka. Cílem bylo nahradit zastaralý adresářový server Sun Directory Server (dále jen Sun DS) verze 5.2 za novější software, který bude možné dále patchovat a udržovat. V našem případě se jednalo o nahrazení dvou multi-master serverů a několik kusů pobočkových replik za nový software.
Dobrou zprávou je, že Fedora Directory server a Sun DS mají stejný původní základ. Tento fakt migrace celkově usnadnil. Špatnou zprávou je změna replikačního protokolu mezi produkty Sun DS a 389 DS. Tedy replikaci nativní cestou mezi těmito sw produkty není možné bezpečně provozovat. Co se týče operačních systémů pod vlastní adresářové servery, tak se přechází ze Solaris 10 na Linux, konkrétně na Oracle Linux verze 6.2.
Migrace Sun DS 5.2 na 389DS
Adresářový server Sun DS ve verzi 5.2 byl původně použit jako zdroj uživatelů pro Unixové prostředí a později byl Sun DS zdrojem informací i na další aplikaci – portál. Využití jednoho adresářového serveru pro více aplikací, které částečně sdílí data je celkem logické a chválihodné, ovšem nese sebou několik problémů.
- Jakýkoliv upgrade aplikace portálu je potencionálně nebezpečná operace, protože zasahuje do struktury uživatelských účtů.
- Portál je podstatně více vytěžující aplikace oproti vyhledání login údajů pro OS.
- Datové struktury portálu zvětšili objem dat adresářového serveru. Všechna tato data jsou pak replikována i na další pobočky (slave repliky) bez reálného využití, což bylo v podstatě zbytečné.
Vzhledem k výše popsaným nevýhodám jednotného adresářového serveru bylo v minulosti provedeno oddělení a došlo ke vzniku samostatných adresářových serverů. Replikace dat o uživatelích po oddělení serverů byla nastavena jednosměrně a technická realizace byla pomocí skriptu, který přenášel pouze relevantní data z jednoho LDAP do druhého.
Z výše popsaného je zřejmé, že migraci dat na nový software bylo nutné provést i s očištěním dat. S rozdělením adresářových serverů již schémata a data nikdo nevyčistil. Očištění dat spočívalo v analýze struktury, zkoumáním access logů jaká data jsou a jaká nejsou využívána. Následovalo několik skriptovaných ldapsearch příkazů. Výsledkem je soubor ve formátu ldif, který je možné importovat do nového adresářového serveru. Velikost dat jsme zmenšili více jak 20x.
Jak je to se schématy
S novým adresářovým serverem je více než vhodné použít i nová schémata – usnadníte si tím problémy při update do budoucna. Navíc původní schémata byla opepřena o spoustu tříd pro data, která jsme vyfiltrovali. Díky tomuto požadavku byla celá operace se schématy poměrně zajímavá. Šlo o to, vybrat co nejlepší kombinaci standardně dodávaných schémat, aby byla pokryta datová struktura uvnitř a co nejméně definic ve schématech přepisovat, upravovat, rozšiřovat. Výsledek po dvou dnech ladění stojí za to :). Standardní schémata s instalací byla rozšířena o další přímo z 389 DS, dvě definice byly pozměněny a do uživatelského souboru schémat 99user.ldif byl doplněn zbytek definic a tříd.
ACI a VLV search listy
Přeneseny musí být i aci (přístupová omezení), v tomto adresářovém serveru pak byly i vlvSearch listy, které využívá OS Solaris. Export obou položek je otázkou položení správného ldapsearch dotazu, import je také bez problémů.
Statistiky
V rámci analýzy prostředí jsme zpracovali statistiky využívání stávajících adresářových serverů. Výsledky byly celkem podle očekávání, poměr čtení/zápis byl jasně ve prospěch čtení. Objevili jsme i zajímavé skutečnosti. Třeba že jeden ze zaměstnanců pouští automatické skripty na monitoring pod svým účtem. V rámci statistik šlo samozřejmě i o analýzu indexů, zda je všechny nejvíce čtené prvky mají správně vytvořené a žádné nechybí (chyběly).
Testování
Protože bylo provedeno celkem radikální očištění datových struktur a zároveň se přecházelo na novou verzi adresářového serveru, bylo nutné vše pořádně otestovat. K tomuto testování jsme si nechali zřídit prostředí blížící se produkci a všechny aplikace napojené adresářové servery byly vyzkoušeny a byla testována jejich bezproblémová funkčnost.
Replikace dat mezi 389 DS a Sun DS
Protože při migraci dojde k náhradě hlavních (master) serverů, pobočkové repliky zůstanou zachovány. Jejich migrace bude provedena postupně tak, jak se budou servery obměňovat za nové. Tento fakt jsme samozřejmě museli zohlednit i v naší nové instalaci. V principu jde o to, že replikace dat mezi 389 DS a Sun DS není podporována. Jako nejvhodnější řešení bylo vybráno čtení auditního logu 389 DS. Získané informace se pak budou importovat do Sun DS, ze kterého následně proběhne replikace dat na pobočky. Výhodou tohoto řešení je nativní způsob replikace na pobočky. Zejména pak po případném výpadku připojení není nutné obsluhovat, kde se má s replikací začít a co vše je třeba zreplikovat. Naopak nevýhodou je nutnost provozu skriptu, který prostředí trochu zesložití a nemožnost automaticky rotovat audit log. Vzhedem k malému objemu měnících se dat by tato skutečnost neměla nijak vadit. Skript je napsaný v Perlu, autorem skriptu je kolega Zdeněk Burda.
Migrace na nový software
Vlastní migrace byla operace na několik hodin. Migrace se prováděla za pracovního dne a bylo třeba zajistit, aby vše proběhlo pokud možno bez výpadku. Nebudu napínat – povedlo se :)
Celé akci samozřejmě předcházela výše uvedená příprava, zkoušení migračního postupu i vlastní časování celé akce. Vzhledem k důležitosti adresářových serverů v organizaci byl každý velký krok následován otestováním funkčnosti tak, aby vše bylo „na jistotu“ a celá akce skončila úspěchem bez výpadku.
Postup migrace
- přepnutí stávajících adresářových serverů Sun DS do režimu pouze pro čtení
- dump dat, očištění dat
- import dat do nového adresářového serveru 389DS, inicializace nové repliky
- otestování funkčnosti všech aplikací na novém serveru
- vypnutí stávajícího adresářového serveru Sun DS, změna IP a první spuštění nového serveru do produkce
- otestování funkčnosti
- vypnutí druhého stávajícího adresářového serveru Sun DS, změna IP a spuštění nového serveru do produkce D89DS, náhrada je kompletní
- otestování funkčnosti
V dalších dvou dnech pak proběhlo zprovoznění skriptu replikace a změna nastavení všech poboček na nový server, ze kterého budou dostávat data. Kolegové mezitím zapracovali a adresářové servery připojili na náš IDM software – CzechIdM – a další správa uživatelů tak bude probíhat přes tento systém. Díky napojení na CzechIdM bude minimalizována řada lidských chyb (překlepy ve jménech, uid uživatele větší nez povolený Unixový rozsah…) a velká část procesu založení uživatele bude automatizována.
Pro zajímavost
Migrovali jsme ze serverů Sun Fire V210 s procesory Sparc 1.3 GHz a 2 GB RAM s OS Solaris na virtuální server (postavený na KVM) s OS Linux. Pro virtuál bylo přiděleno 1GB RAM a 2x cpu vlákno. Zatížení nových serverů se po migraci pohybuje okolo 10%, díky virtualizaci jsme ušetřili spoustu peněz za pořízení nového serveru a zároveň i provozních nákladů zákazníka.
Zaujal Vás tento článek? Řešíte podobnou situaci a potřebujete pomoci? Neváhejte nás kontaktovat na info@bcvsolutions.eu.
