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

Tento článek obsahuje řešení některých běžných chyb konfigurace a dalších problémů, které by mohly bránit 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 kořenový 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í vytváření cíle úložiště NFS.

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

Kontrola nastavení portu

Azure HPC Cache back-endového úložného systému NAS potřebuje přístup pro čtení a zápis k několika portům UDP/TCP. Ujistěte se, že jsou tyto porty v systému NAS přístupné a že provoz na tyto porty je povolený přes všechny brány firewall mezi systémem úložiště a podsítí mezipaměti. Možná bude potřeba, abyste tuto konfiguraci ověřili ve svém datovém centru ve vaší bráně firewall a správci sítě.

Porty se pro systémy úložiště liší 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:

Pokud chcete zjistit konkrétní porty potřebné pro váš systém, použijte následující rpcinfo příkaz. Následující příkaz vypíše porty a naformátuje relevantní výsledky v tabulce. (Místo tohoto termínu použijte IP adresu<storage_IP> systému.)

Tento příkaz můžete vydat z libovolného klienta Linuxu s nainstalovanou infrastrukturou systému souborů NFS. Pokud používáte klienta v podsíti clusteru, může vám 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 povolují neomezený provoz z podsítě Azure HPC Cache rpcinfo podsítě.

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

Kontrola kořenového přístupu

Azure HPC Cache k vytvoření cíle úložiště potřebuje přístup k exportům vašeho systému úložiště. Konkrétně připojí exporty jako ID uživatele 0.

Různé systémy úložiště používají k povolení tohoto přístupu různé metody:

• Servery s Linuxem obecně no_root_squash přidávají do exportované cesty v /etc/exports .
• Systémy NetApp a EMC obvykle řídí přístup pomocí pravidel exportu vázaných na konkrétní IP adresy nebo sítě.

Pokud používáte pravidla exportu, mějte na paměti, že mezipaměť může používat několik různých IP adres z podsítě mezipaměti. Povolte přístup z plného rozsahu možných IP adres podsítě.

Spolupracujte s dodavatelem úložiště NAS a povolte správnou úroveň přístupu k mezipaměti.

Povolení kořenového přístupu k cestám k adresářům

Pro systémy NAS, které exportuje hierarchické adresáře, Azure HPC Cache přístup ke každé úrovni exportu od kořenového adresáře.

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

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

Export /ifs/accounting/payroll je podřízeným objektem /ifs/accounting a je sám /ifs/accounting podřízeným objektem /ifs .

Pokud export přidáte jako cíl HPC Cache úložiště, mezipaměť se skutečně připojí k adresáři mezd a bude k adresáři payroll /ifs/ mezd přistupovat. Proto Azure HPC Cache přístup ke /ifs kořenovému adresáři pro přístup k /ifs/accounting/payroll exportu.

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é popisovače souboru pro stejný soubor, pokud se soubor načítá z různých exportů. Klient může například připojit soubor a /ifs/accounting přistupovat k souboru payroll/2011.txt . Jiný klient připojí soubor /ifs/accounting/payroll a přistupuje k souboru 2011.txt . V závislosti na tom, jak systém úložiště přiřazovat popisovače souborů, můžou tito dva klienti obdržet stejný soubor s různými popisovači souboru (jeden pro a <mount2>/payroll/2011.txt jeden pro <mount3>/2011.txt ).

Back-endový systém úložiště uchovává interní aliasy pro popisovače souborů, Azure HPC Cache ale nedokáže říct, které popisovače souboru ve svém 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 této možné kolizi souborů u souborů ve více exportech, nástroj Azure HPC Cache automaticky připojí export, který je k dispozici pro nástroj Shallowest, v cestě (v tomto příkladu) a použije popisovač souboru z tohoto /ifs exportu. Pokud více exportů používá stejnou základní cestu, Azure HPC Cache k této cestě přístup od kořenového adresáře.

Úprava omezení velikosti paketů VPN

Pokud máte síť VPN mezi mezipamětí a zařízením NAS, může síť VPN blokovat 1500-byte ethernetové pakety v plné velikosti. K tomuto problému může dojít v případě, že se velké výměny mezi NAS a instancí Azure HPC Cache nekončí, ale menší aktualizace fungují podle očekávání.

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

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

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

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

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

  Toto jsou možnosti v příkazu:

  • -M do – Ne fragmentovat
  • -c 1 – Odeslání pouze jednoho paketu
  • -s 1472 – Nastavte velikost datové části na 1 472 bajtů. Jedná se o maximální velikost datové části paketu o velikosti 1 500 byte po zúč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 1 472 bajty, pravděpodobně došlo k problému s velikostí paketu.

Pokud chcete tento problém vyřešit, možná budete muset nakonfigurovat MSS a nastavit vzdálený systém tak, aby správně detekovat maximální velikost snímku. Další informace VPN Gateway v dokumentaci k parametrům protokolu IPsec/IKE.

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

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ími systémy POSIX nebo systém UNIX zabezpečení.

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í.

U systémů, které používají seznamy ACL, 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 přístupové mezipaměti. Neexistuje ovládací prvek, který by mohl zapnout mezipaměť přístupu, ale můžete otevřít lístek podpory a požádat ho o povolení pro ovlivněné cíle úložiště v systému mezipaměti.

Další kroky

Pokud máte problém, který v tomto článku nebyl vyřešen, požádejte o odbornou pomoc podporu.