Ang muling pag-export ng NFS sa VPN ay hindi pagpapasa ng packet

Isang makina ng Linux ang sumasali sa isang VPN, nag-mount ng malayong NFS export at pagkatapos ay naglilingkod sa mount na iyon sa ibang pangkat ng mga kliyente. Ang kaayusang ito ay mukhang routing na may dagdag na hakbang, at iyon ang unang maling palagay. Ang gitnang makina ay kliyente ng upstream server at server para sa downstream na mga kliyente, at lumalahok ito sa dalawang ugnayan ng file service. Ang pagpapasa ng packet ay walang opinyon tungkol sa mga handle ng file, pag-lock o pagkakakilanlan ng filesystem; ang muling pag-export ay mayroon.

Simulan sa pagtatanong kung maaabot ng downstream na mga kliyente ang orihinal na server nang direkta. Kung kaya nila, opsyonal ang gitnang makina.

Tatlong modelo, tatlong kuwento ng consistency

Ang direktang mount ang pinakasimple: bawat kliyente ay nag-mount ng orihinal na server sa tunnel, at ang patakaran sa export ng server na iyon ang namamahala sa access. Ang muling pag-export ay ang gitnang makina na nagpapakita ng ibang hangganan ng serbisyo, na kapaki-pakinabang kapag ang network sa panig ng kliyente ay hindi dapat direktang maabot ang server. Ang replikasyon ay isang ikatlong modelo, at inililipat nito ang tanong mula sa consistency tungo sa synchronisation at paglutas ng conflict.

Huwag ilarawan ang replikadong kopya na parang buhay na muling pag-export. Iba ang mga mode ng pagpalya, at ang user na umaasa na ang bawat operasyon ay aabot sa orihinal na filesystem ay mabibigla sa pagkawala ng link.

Ang pagkakakilanlan ay nabubuhay nang mas mahaba kaysa sa utos ng mount

Ang mga muling pag-export ay nangangailangan ng tahasang ID ng filesystem, at ang pagkakakilanlang iyon ay dapat tumagal sa mga restart at muling pagbuo ng configuration. Maliwanag ang dokumentasyon ng kernel tungkol sa pangangailangan, at nagbabala rin ito na crossmnt ay hindi nag-aalis ng pangangailangang i-export ang mga child filesystem kasama ang kanilang sariling mga ID. Ang puno ng direktoryo na mukhang tuloy-tuloy sa user ay maaaring tumawid sa ilang hangganan ng filesystem. Ang kasalukuyang nfs-utils ay maaaring maglaan ng mga ID nang awtomatiko para sa mga sinusuportahang configuration, at kapag ginawa nito, ang database nito ay nagiging bahagi ng estado ng gateway. Ituring ang mga ID na iyon bilang pagkakakilanlan ng serbisyo at hindi bilang mga file na itatapon.

Ang mga handle ng file ang isa pang hangganan ng pagkakakilanlan: binabalot ng muling pag-export ang orihinal na handle, na nagpapalaki nito at maaaring lumampas sa limitasyon ng isang kliyente. Ang matagumpay na mount ay hindi nagpapatunay na ang bawat layout ng export ay tugma.

Hindi lahat ng tampok ng NFS ay nakakaligtas sa gitnang makina

Sinasabi ng gabay ng kernel sa muling pag-export na hindi sinusuportahan ng server na muling nag-export ang pag-lock o mga kahilingan sa delegation. Ang mga aplikasyong umaasa sa mga operasyong iyon ay nangangailangan ng ibang landas o disenyong na-verify laban sa mga ito. Ang matagumpay na mount at gumaganang listahan ng direktoryo ay hindi nagpapakita na gumagana ang tunay na mga operasyon ng aplikasyon.

Mahalaga rin ang pagkakakilanlan ng user at patakaran sa export sa bawat pagtalon. Ang pag-login sa VPN ay nagpapatunay na ang isang kalahok sa network ay na-authenticate; hindi nito binibigyan ng awtoridad ang isang user ng NFS, at hindi nito ipinapasa ang mga kredensyal ng kliyente sa gateway.

Ang gateway ay may dalawang dependency sa upstream

Ang gateway ay umaasa sa VPN para sa upstream na mount at sa upstream na server para sa filesystem mismo. Ang lokal na proseso ng export na tumatakbo pa ay hindi kayang gawing malusog ang hindi available na storage. Planuhin ang pagkakasunod-sunod ng pagsisimula, pag-uugali sa muling pagkonekta at mga restart ng server, kasama na kung ano ang mangyayari sa mga handle ng file na hawak na ng mga kliyente. Ang kliyenteng nag-mount sa gateway at nawala ang handle ay kailangang mag-mount muli, at ito ay isang pangyayaring pang-operasyon at hindi transparent na pagbawi.

Kung ang tanging kailangan ng requirement ay maabot ang pribadong IP, ang direktang routing sa orihinal na server ang mas simpleng arkitektura. Ang muling pag-export ay dapat umiiral para sa dahilang nananatili kapag isinulat.

Subukan ang workload, hindi ang mount

Sanayin ang tunay na workload ng file sa kontroladong kapaligiran: ang mga operasyong ginagawa ng aplikasyon, ang mga laki ng file na ginagamit nito at ang concurrency na inaasahan nito. Bantayan ang mga puwang sa tampok at hindi lamang ang mga error sa transport. Pagkatapos itala kung aling modelo ang pinili mo at bakit, dahil kung hindi ay ipapalagay ng susunod na tao na ang gateway ay isang router.

Ang muling pag-export ay lehitimo kapag umiiral ito para sa sadyang dahilan, tulad ng isyolang network ng kliyente o kontroladong hangganan ng bersyon. Ito ay isang masamang aksidente, at ang pagkakaiba ay kung may nagpasya nito.