Řešení potíží s konfigurací NAS a cílovým úložištěm NFS

  • Článek

Tento článek obsahuje řešení některých běžných chyb konfigurace a dalších problémů, které by mohly bránit službě Azure HPC Cache v přidání systému úložiště NFS jako cíle úložiště.

Tento článek obsahuje podrobnosti o tom, jak zkontrolovat porty a jak povolit potřebný přístup k systému NAS. Obsahuje také podrobné informace o méně běžných problémech, které můžou způsobit selhání vytvoření cíle úložiště NFS.

Tip

Před použitím této příručky si přečtěte požadavky pro cíle úložiště NFS.

Pokud řešení vašeho problému tady není uvedené, otevřete lístek podpory, aby s vámi služba a podpora Microsoftu mohly spolupracovat, abyste mohli problém prošetřit a vyřešit.

Zajištění dostatečných vláken připojení

Velké systémy HPC Cache prosí více požadavků na připojení k cíli úložiště. Pokud například cíl úložiště používá modul Ubuntu Linux nfs-kernel-server , výchozí počet vláken démona NFS může být až osm. Zvyšte počet vláken na 128 nebo 256, což jsou vhodnější čísla pro podporu střední nebo velké mezipaměti HPC Cache.

Počet vláken v Ubuntu můžete zkontrolovat nebo nastavit pomocí hodnoty RPCNFSDCOUNT v /etc/init.d/nfs-kernel-server.

Kontrola nastavení portů

Azure HPC Cache potřebuje přístup pro čtení a zápis k několika portům UDP/TCP v back-endovém systému úložiště NAS. Ujistěte se, že jsou tyto porty přístupné v systému NAS a že provoz do těchto portů je povolený prostřednictvím všech bran firewall mezi systémem úložiště a podsítí mezipaměti. K ověření této konfigurace možná budete muset pracovat se správci brány firewall a sítě pro vaše datové centrum.

Porty se liší pro systémy úložiště od různých dodavatelů, proto při nastavování cíle úložiště zkontrolujte požadavky vašeho systému.

Obecně platí, že mezipaměť potřebuje přístup k těmto portům:

Protokol Port Service
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 připojeno
TCP/UDP 4047 status

Pokud chcete zjistit konkrétní porty potřebné pro váš systém, použijte následující rpcinfo příkaz. Tento příkaz níže zobrazí seznam portů a naformátuje relevantní výsledky v tabulce. (Místo ip adresy vašeho systému použijte IP adresu < vašeho systému.> storage_IP termín.)

Tento příkaz můžete vydat z libovolného klienta s Linuxem, který má nainstalovanou infrastrukturu NFS. Pokud používáte klienta v podsíti clusteru, může také pomoct ověřit připojení mezi podsítí a systémem úložiště.

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

Ujistěte se, že všechny porty vrácené dotazem rpcinfo umožňují neomezený provoz z podsítě služby Azure HPC Cache.

Zkontrolujte tato nastavení na samotném serveru NAS i na všech branách firewall mezi systémem úložiště a podsítí mezipaměti.

Kontrola nastavení squashu v kořenovém adresáři

Nastavení root squash může narušit přístup k souborům, pokud jsou nesprávně nakonfigurované. Měli byste zkontrolovat, jestli jsou nastavení pro každý export úložiště a odpovídající zásady přístupu klientů služby HPC Cache vhodné.

Root squash zabraňuje odesílání požadavků místnímu kořenovému adresáři superuživatele v klientovi do back-endového systému úložiště jako kořenového adresáře. Znovu přiřazuje požadavky z kořenového adresáře na neprivilegované ID uživatele (UID), jako je "nikdo".

Tip

Předchozí verze služby Azure HPC Cache vyžadovaly systémy úložiště NAS, aby umožňovaly kořenový přístup ze služby HPC Cache. Pokud nechcete, aby klienti služby HPC Cache měli k exportu kořenový přístup, nemusíte u cílového exportu povolit kořenový přístup.

Root squash lze nakonfigurovat v systému HPC Cache na těchto místech:

  • Ve službě Azure HPC Cache – Pomocí zásad klientského přístupu nakonfigurujte root squash pro klienty, kteří odpovídají konkrétním pravidlům filtru. Zásady přístupu klienta jsou součástí každé cesty k cílovému oboru názvů úložiště NFS.

    Výchozí zásady klientského přístupu nevyvolá root.

  • Při exportu úložiště – Systém úložiště můžete nakonfigurovat tak, aby znovu přiřazuje příchozí požadavky z kořenového adresáře na neprivilegované ID uživatele (UID).

Pokud váš systém úložiště exportuje kořen, měli byste aktualizovat pravidlo přístupu klienta služby HPC Cache pro tento cíl úložiště tak, aby také squash root. Pokud ne, můžete mít problémy s přístupem při pokusu o čtení nebo zápis do back-endového systému úložiště prostřednictvím služby HPC Cache.

Tato tabulka znázorňuje chování různých scénářů squash root při odeslání požadavku klienta jako UID 0 (root). Scénář označený znakem * se nedoporučuje , protože může způsobit problémy s přístupem.

Nastavení UID odesílané z klienta UID odeslané ze služby HPC Cache Efektivní UID v back-end úložišti
žádná kořenová squash 0 (kořen) 0 (kořen) 0 (kořen)
root squash pouze ve službě HPC Cache 0 (kořen) 65534 (nikdo) 65534 (nikdo)
*root squash pouze v úložišti NAS 0 (kořen) 0 (kořen) 65534 (nikdo)
root squash ve společnosti HPC Cache a NAS 0 (kořen) 65534 (nikdo) 65534 (nikdo)

(UID 65534 je příkladem. Když v zásadách přístupu klienta zapnete root squash, můžete si UID přizpůsobit.)

Kontrola přístupu k cestám k adresářům

V případě systémů NAS, které exportují hierarchické adresáře, zkontrolujte, jestli má Služba Azure HPC Cache odpovídající přístup ke každé úrovni exportu v cestě k souborům, které používáte.

Systém může například zobrazit tři exporty, jako jsou tyto:

  • /ifs
  • /ifs/accounting
  • /ifs/accounting/payroll

Export /ifs/accounting/payroll je dítě /ifs/accounting, a /ifs/accounting je sám o sobě dítě /ifs.

Pokud export přidáte payroll jako cíl úložiště služby HPC Cache, mezipaměť se skutečně připojí /ifs/ a přistupuje k adresáři mzdových účtů. Azure HPC Cache proto potřebuje dostatečný přístup pro /ifs přístup k exportu /ifs/accounting/payroll .

Tento požadavek souvisí se způsobem, jakým mezipaměť indexuje soubory a zabraňuje kolizím souborů pomocí popisovačů souborů, které poskytuje systém úložiště.

Systém NAS s hierarchickými exporty může poskytnout různým popisovačům souborů pro stejný soubor, pokud se soubor načte z různých exportů. Klient může například připojit /ifs/accounting soubor a přistupovat k němu payroll/2011.txt. Jiný klient připojí /ifs/accounting/payroll soubor a přistupuje k němu 2011.txt. V závislosti na tom, jak systém úložiště přiřazuje popisovače souborů, mohou tito dva klienti obdržet stejný soubor s různými popisovači souborů (jeden pro <mount2>/payroll/2011.txt a druhý pro <mount3>/2011.txt).

Back-endový systém úložiště uchovává interní aliasy pro popisovače souborů, ale Azure HPC Cache nedokáže zjistit, které popisovače souborů v indexu odkazují na stejnou položku. Je tedy možné, že mezipaměť může mít různé zápisy uložené v mezipaměti pro stejný soubor a použít změny nesprávně, protože neví, že se jedná o stejný soubor.

Aby se zabránilo tomuto možnému kolizi souborů u souborů ve více exportech, Azure HPC Cache automaticky připojí k cestě/ifs (v příkladu) mělký dostupný export a použije popisovač souboru z tohoto exportu. Pokud více exportů používá stejnou základní cestu, azure HPC Cache potřebuje k této cestě přístup.

Úprava omezení velikosti paketů VPN

Pokud máte síť VPN mezi mezipamětí a zařízením NAS, může síť VPN blokovat 1500 bajtů ethernetových paketů s plnou velikostí. K tomuto problému může dojít v případě, že se nedokončí velké výměny mezi serverem NAS a instancí služby Azure HPC Cache, ale menší aktualizace fungují podle očekávání.

Neexistuje jednoduchý způsob, jak zjistit, jestli má váš systém tento problém, pokud neznáte podrobnosti o konfiguraci sítě VPN. Tady je několik metod, které vám můžou pomoct zkontrolovat tento problém.

  • Pomocí výsuvků paketů na obou stranách sítě VPN můžete zjistit, které pakety se úspěšně přenášejí.

  • Pokud vaše síť VPN umožňuje příkazy ping, můžete otestovat odesílání paketu v plné velikosti.

    Pomocí těchto možností spusťte příkaz ping přes síť VPN na server NAS. (Místo IP adresy systému úložiště použijte IP adresu < vašeho systému úložiště.> storage_IP hodnota.)

    ping -M do -s 1472 -c 1 <storage_IP>

    Toto jsou možnosti v příkazu:

    • -M do - Nestřílejte
    • -c 1 - Odeslat pouze jeden paket
    • -s 1472 - Nastavte velikost datové části na 1472 bajtů. Jedná se o maximální datovou část velikosti paketu o velikosti 1500 bajtů po účtování režie sítě Ethernet.

    Úspěšná odpověď vypadá takto:

    PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms

    Pokud příkaz ping selže s 1472 bajty, pravděpodobně došlo k problému s velikostí paketů.

Pokud chcete tento problém vyřešit, možná budete muset nakonfigurovat upnutí MSS na VPN, aby vzdálený systém správně rozpoznal maximální velikost rámu. Další informace najdete v dokumentaci k parametrům protokolu IPsec/IKE služby VPN Gateway.

V některých případech může pomoct změna nastavení MTU pro Azure HPC Cache na 1400. Pokud ale omezíte MTU v mezipaměti, musíte také omezit nastavení MTU pro klienty a back-endové systémy úložiště, které pracují s mezipamětí. Podrobnosti najdete v tématu Konfigurace dalších nastavení služby Azure HPC Cache.

Kontrola stylu zabezpečení seznamu ACL

Některé systémy NAS používají hybridní styl zabezpečení, který kombinuje seznamy řízení přístupu (ACL) s tradičním poSIX nebo systém UNIX zabezpečením.

Pokud váš systém hlásí svůj styl zabezpečení jako systém UNIX nebo POSIX bez zahrnutí zkratky "ACL", tento problém vás neovlivní.

Pro systémy, které používají seznamy ACL, musí Azure HPC Cache sledovat další hodnoty specifické pro uživatele, aby bylo možné řídit přístup k souborům. To se provádí povolením mezipaměti přístupu. Neexistuje uživatelský ovládací prvek, který by zapnul mezipaměť přístupu, ale můžete otevřít lístek podpory a požádat o povolení ovlivněných cílů úložiště v systému mezipaměti.

Další kroky

Pokud máte problém, který se v tomto článku neřešil, obraťte se na podporu a požádejte o odbornou pomoc.