Administrace Lotus Domino/Notes – 9/10

Původně jsem do plánu o čem psát zahrnul i návrh implementace a jaké to může mít výhody a nevýhody a teď, když mě čeká to napsat, tak přemýšlím, co vlastně psát. Tak se necháme překvapit, co z toho vyjde 🙂

Pokud máte jeden server tak je všechno (skoro) jasné. Prostě na něj připojíte uživatele, rozmyslet můžete jedině strukturu certifikátů (osobně jsem pro plochou, tedy Jméno/Organizace, pokud hierarchická nebude mít nějaký zvláštní smysl), vymyslet jak odesílat poštu do internetu (přímo nebo přes relay, kde relay odlehčí serveru, ale při posílání napřímo vidíte, kde jsou problémy s odesíláním) a jak ji přijímat (zase přes nějakou relay nebo přímo, tady je ta relay u providera asi příjemnější, protože firewall stačí otevřít na konkrétní externí adresu a hlavně už tam mohou vyřešit antivir a antispam). Víc rozhodování asi u jednoho serveru není.

Dva servery už přinášejí něco navíc. Za prvé je otázkou, proč jsou dva a jestli by třeba uživatelé na každém z nich nemohli mít vlastní OU v certifikátu. Pak je otázka jak odesílat poštu ven – buď oba budou komunikovat přes relay (což je asi dost pravděpodobné), nebo se vše bude routovat na jeden z nich a ten to bude předávat dál. Zatímco případ první – oba jedou přes relay – nastavíte snadno zadáním adresy relay serveru v konfiguračním dokumentu; u případu druhého musíte jít cestou doménových dokumentů a dokumentů spojení. Příjem pošty je pak skoro jasný – půjde primárně na jeden ze serverů, pokud to síť umožní tak by bylo hezké mít druhý server zadaný pro příjem s vyšším MX, aby fungoval jako záloha.

Druhé použití dvou serverů může být v rozdělení jejich rolí – jeden bude fungovat pro poštu a druhý pro aplikace. Smysl to dává v jejich vytížení, poštu používá každý a aktivně, takže bude celkem zatížený, na aplikační zase dáte veškeré aplikace a třeba Sametime pro instant messaging (na to snad rozumný překlad ani neexistuje). Podle zkušeností je tohle rozdělení celkem standardní a dělá to dost firem.

Tři a více serverů už konečně přinášejí to správné vzrušení, jak to nakonfigurovat. Zní to krásně, ve finále ale stejně všichni skončíme u hvězdy, protože dělat spojení každý s každým, když máte 50 serverů je trochu makačka (přestože jsem to už viděl), a liniové (tedy každý ví o svém sousedovi) je zase hrozně zdlouhavé, než všechny servery spolu proreplikují. Takže hvězda nám vychází jako nejlepší, při větším počtu serverů se vyplatí jeden z nich dedikovat jenom pro serverovou komunikaci a vůbec tam uživatele nepustit.

Schéma infrastruktury

Schéma nakresleno pomocí kreslítka Gliffy.com – aneb Visio přes internet a zdarma

Nastavení je jasné – jeden server má dokumenty spojení na všechny ostatní, každý další jenom na ten hlavní server. Každý server navíc bude mít v server dokumentu nastavenou jinou NNN/DNN (Notes/Domino Named Network, podle toho co kdo preferuje), aby pošta chodila také hezky přes centrální server a nezkoušela se spojit napřímo. Díky centrálnímu serveru, přes který poběží veškerá pošta a replikace, tak máte i jedno místo, kde stojí za to nainstalovat antivir. Asi to bude levnější než to mít všude a hlavně tím šetříte síly těm dalším serverům (ano, emaily poslané v rámci jednoho serveru nepůjdou přes hlavní server a nebudou tedy skenované, to je trochu nevýhoda – ale udělejte na tom hlavním repliky všech mailových databází a máte také jedno místo pro zálohování a viry zjistíte také, byť se zpožděním).

Nastavení do hvězdy může mít (tedy má, ale otázkou je, zda se vám to projeví) nevýhodu při tvorbě replik nebo přesouvání uživatelů na jiný server. Díky tomu, že neexistuje přímé spojení mezi podřízenými servery, tak při přesunu uživatele z jednoho serveru na druhý nedojde k automatickému vytvoření jeho poštovní schránky. Řešení jsou dvě – vytvořit dočasný dokument spojení nebo uživatele přesunout na dvakrát – nejdřív na hlavní server a pak už na ten cílový.

Více serverů také umožňuje bezpečný přístup z internetu do vnitřní sítě pomocí takzvaného průchozího serveru (passthru server). Server umístíte do DMZ, ze které necháte do vnitřní sítě přístupný pouze port 1352. Poté trochu poladíte bezpečnost v server dokumentu, konkrétně na záložce Security sekci Passthru access. U serveru, který je umístěn v DMZ vyplníte do pole Route through jména, která mají právo připojit se přes internet na vnitřní servery (tedy klidně to můžete umožnit jenom vedoucím pracovníkům). U serverů v interní síti zase naopak naplníte pole Access this server (ve stejné sekci) jmény lidí, kteří mají právo přistupovat zvenku na daný server. Díky tomu jste schopni některým lidem umožnit používání serverů pouze z vnitřní sítě, některým plné používání i z internetu a dalším něco mezi – tedy s poštovním serverem by třeba replikovat mohli, s aplikačním nikoliv.

Co dál k implementaci, člověk by řekl, že už asi nic. Samozřejmě jsou další zkušenosti, jak si usnadnit práci s konfigurací (důsledně používat skupiny, aby se do server dokumentu nemuselo vůbec zasahovat, v konfiguračním dokumentu pro všechny servery nastavit maximum společných věcí a pak udělat konfigurační dokumenty pro konkrétní server, který potřebuje něco málo jinak – a zdokumentovat, proč je jich víc, to je asi úplně nejdůležitější). Určitě používat CA, která usnadní práci při registraci lidí (jak jsem ji začal používat, tak jsem okamžitě zapomněl heslo k certifikátu, naštěstí to nevadilo). A to je asi opravdu vše.

Ještě přemýšlím, zda pro ten demo příklad, který jsem nakreslil výše, sem hodit jak by vypadalo nastavení Domino Directory s komentářem, co vše je tam nastaveno a proč, ale to je otázka na vás – má něco takového smysl, nebo je to zbytečné?

1 komentář

  1. dobry den, myslim si ze napad s popsanim co a jak je nastaveno a hlavne proc tam bychuvital. Obcas by me zajimalo co ovlivnim pokud nastavim v nejakem poli jine parametry zejmena pokud se jedna o pole kde vybiram z nekolika moznosti. Zajimali by me hlavne server dokumenty, configuration dokumenty, connection dokumenty a domain dokumenty.

Leave a Reply