Opětovný export NFS přes VPN není přeposílání paketů

Linuxový stroj se připojí k VPN, připojí vzdálený export NFS a potom tento přípojný bod poskytuje další skupině klientů. Toto uspořádání vypadá jako směrování s kroky navíc, a to je první chybný předpoklad. Prostřední stroj je klientem nadřazeného serveru a serverem pro podřízené klienty a účastní se obou vztahů souborové služby. Přeposílání paketů nemá názor na handle souborů, zamykání ani identitu systému souborů; opětovný export ano.

Začněte otázkou, zda by se podřízení klienti mohli dostat k původnímu serveru přímo. Pokud ano, prostřední stroj je volitelný.

Tři modely, tři příběhy konzistence

Přímé připojení je nejjednodušší: každý klient připojí původní server přes tunel a exportní politika tohoto serveru řídí přístup. Opětovný export je prostřední stroj, který představuje jinou hranici služby, což je užitečné, když síť obrácená ke klientům nesmí dosáhnout serveru přímo. Replikace je třetí model a mění otázku z konzistence na synchronizaci a řešení konfliktů.

Nepopisujte replikovanou kopii, jako by šlo o živý opětovný export. Režimy selhání se liší a uživatel, který očekává, že každá operace dosáhne původního systému souborů, bude během výpadku spojení překvapen.

Identita přežívá příkaz k připojení

Opětovné exporty potřebují explicitní ID systému souborů a tato identita musí přežít restarty a přestavby konfigurace. Dokumentace jádra je ohledně požadavku jasná a také varuje, že crossmnt neodstraňuje potřebu exportovat podřízené systémy souborů s jejich vlastními ID. Adresářový strom, který se uživateli jeví jako souvislý, může překročit několik hranic systému souborů. Současné nfs-utils umějí přidělovat ID automaticky pro podporované konfigurace, a když to udělají, jejich databáze se stane součástí stavu brány. Považujte tato ID za identitu služby, nikoli za jednorázové soubory.

Handly souborů jsou další hranicí identity: opětovný export obaluje původní handle, čímž ho zvětšuje, a může překročit limit klienta. Úspěšné připojení nedokazuje, že každé uspořádání exportu je kompatibilní.

Ne každá funkce NFS přežije prostřední stroj

Průvodce opětovným exportem v jádru uvádí, že server provádějící opětovný export nepodporuje zamykání ani žádosti o delegaci. Aplikace, které na těchto operacích závisí, potřebují jinou cestu nebo návrh ověřený proti nim. Úspěšné připojení a funkční výpis adresáře neukazují, že skutečné operace aplikace fungují.

Identita uživatele a exportní politika jsou důležité i na každém skoku. Přihlášení VPN dokazuje, že se účastník sítě autentizoval; neopravňuje uživatele NFS a nepředává přihlašovací údaje klienta přes bránu.

Brána má dvě závislosti směrem nahoru

Brána závisí na VPN kvůli nadřazenému připojení a na nadřazeném serveru kvůli samotnému systému souborů. Místní exportní proces, který stále běží, nemůže nedostupné úložiště udělat zdravým. Naplánujte pořadí spouštění, chování při opětovném připojení a restarty serveru, včetně toho, co se stane s handly souborů, které klienti už drží. Klient, který se připojil přes bránu a ztratil svůj handle, potřebuje nové připojení, a to je provozní událost, nikoli průhledné zotavení.

Pokud vše, co požadavek kdy potřeboval, byla dostupnost privátních IP adres, je přímé směrování na původní server jednodušší architekturou. Opětovný export by měl existovat z důvodu, který přežije, když se zapíše.

Testujte pracovní zátěž, ne připojení

Procvičte skutečnou souborovou zátěž v kontrolovaném prostředí: operace, které aplikace provádí, velikosti souborů, které používá, a souběžnost, kterou očekává. Sledujte mezery ve funkcích, ne jen chyby přenosu. Potom si poznamenejte, který model jste zvolili a proč, protože jinak další člověk bude předpokládat, že brána je router.

Opětovný export je oprávněný, když existuje z úmyslného důvodu, například izolovaná klientská síť nebo kontrolovaná hranice verze. Je to špatná náhoda a rozdíl je v tom, zda o tom někdo rozhodl.