VPN દ્વારા NFS ફરી-નિકાસ પેકેટ ફોરવર્ડિંગ નથી

એક Linux બોક્સ VPN માં જોડાય છે, દૂરસ્થ NFS એક્સપોર્ટ માઉન્ટ કરે છે અને પછી એ માઉન્ટને બીજા ક્લાયન્ટ સમૂહને સેવા આપે છે. આ ગોઠવણ વધારાના પગલાં સાથે રાઉટિંગ જેવી લાગે છે, અને તે પહેલી ખોટી ધારણા છે. વચ્ચેનું મશીન ઉપરના સર્વરનું ક્લાયન્ટ અને નીચેના ક્લાયન્ટ માટે સર્વર છે, અને તે બંને ફાઇલ-સેવા સંબંધોમાં ભાગ લે છે. પેકેટ ફોરવર્ડિંગને ફાઇલહેન્ડલ, લોકિંગ કે ફાઇલસિસ્ટમ ઓળખ વિશે કોઈ મત નથી; ફરી-નિકાસને છે.

શરૂ કરો એ પ્રશ્નથી કે નીચેના ક્લાયન્ટ મૂળ સર્વર સુધી સીધા પહોંચી શકે કે નહીં. જો પહોંચી શકે, તો વચ્ચેનું મશીન વૈકલ્પિક છે.

ત્રણ મોડેલ, સુસંગતતાની ત્રણ વાર્તાઓ

સીધું માઉન્ટ સૌથી સરળ છે: દરેક ક્લાયન્ટ ટનલ દ્વારા મૂળ સર્વર માઉન્ટ કરે છે, અને તે સર્વરની એક્સપોર્ટ નીતિ પ્રવેશ નિયંત્રિત કરે છે. ફરી-નિકાસ એ વચ્ચેના મશીન દ્વારા અલગ સેવા સીમા રજૂ કરવી છે, જે ત્યારે ઉપયોગી છે જ્યારે ક્લાયન્ટ તરફનું નેટવર્ક સીધું સર્વર સુધી પહોંચવું ન જોઈએ. નકલીકરણ ત્રીજું મોડેલ છે, અને તે પ્રશ્નને સુસંગતતામાંથી સિંક્રોનાઇઝેશન અને સંઘર્ષ નિરાકરણ તરફ ફેરવે છે.

નકલ કરેલી કોપીને જીવંત ફરી-નિકાસ જેવી ગણીને વર્ણવો નહીં. નિષ્ફળતાના પ્રકાર અલગ છે, અને જે વપરાશકર્તા અપેક્ષા રાખે છે કે દરેક કામગીરી મૂળ ફાઇલસિસ્ટમ સુધી પહોંચશે, તે લિંક વિક્ષેપ દરમિયાન આશ્ચર્ય પામશે.

ઓળખ માઉન્ટ આદેશ કરતાં વધુ જીવે છે

ફરી-નિકાસને સ્પષ્ટ ફાઇલસિસ્ટમ ID ની જરૂર છે, અને તે ઓળખ પુનઃપ્રારંભ અને કન્ફિગરેશન પુનઃનિર્માણ સહન કરવી જોઈએ. કર્નલ દસ્તાવેજીકરણ જરૂરિયાત વિશે સ્પષ્ટ છે, અને તે ચેતવણી પણ આપે છે કે crossmnt બાળ ફાઇલસિસ્ટમને તેમના પોતાના ID સાથે નિકાસ કરવાની જરૂરિયાત દૂર કરતું નથી. વપરાશકર્તાને સતત લાગતું ડિરેક્ટરી વૃક્ષ ઘણી ફાઇલસિસ્ટમ સીમાઓ પાર કરી શકે છે. વર્તમાન nfs-utils સમર્થિત કન્ફિગરેશન માટે ID આપમેળે ફાળવી શકે છે, અને જ્યારે એમ કરે છે, ત્યારે તેનો ડેટાબેઝ ગેટવેની સ્થિતિનો ભાગ બને છે. તે ID ને નિક્ષેપણયોગ્ય ફાઇલો નહીં, સેવા ઓળખ તરીકે ગણો.

ફાઇલહેન્ડલ બીજી ઓળખ સીમા છે: ફરી-નિકાસ મૂળ હેન્ડલ લપેટે છે, જે તેને મોટું બનાવે છે અને ક્લાયન્ટની મર્યાદા વટાવી શકે છે. સફળ માઉન્ટ સાબિત કરતું નથી કે દરેક એક્સપોર્ટ લેઆઉટ સુસંગત છે.

દરેક NFS સુવિધા વચ્ચેના મશીનમાંથી પસાર થતી નથી

કર્નલની ફરી-નિકાસ માર્ગદર્શિકા જણાવે છે કે ફરી-નિકાસ કરતું સર્વર લોકિંગ કે પ્રતિનિધિત્વ વિનંતીઓને સમર્થન આપતું નથી. તે કામગીરી પર આધાર રાખતી એપ્લિકેશનોને બીજો માર્ગ કે તેમની સામે ચકાસાયેલી ડિઝાઇનની જરૂર છે. સફળ માઉન્ટ અને કાર્યરત ડિરેક્ટરી સૂચિ એપ્લિકેશનની વાસ્તવિક કામગીરી ચાલે છે તેમ દર્શાવતાં નથી.

વપરાશકર્તા ઓળખ અને એક્સપોર્ટ નીતિ દરેક પગલે પણ મહત્વપૂર્ણ છે. VPN લોગિન સાબિત કરે છે કે નેટવર્ક સહભાગીએ પ્રમાણીકરણ કર્યું છે; તે NFS વપરાશકર્તાને અધિકૃત કરતું નથી, અને ગેટવે દ્વારા ક્લાયન્ટની ઓળખપત્રો મોકલતું નથી.

ગેટવેની બે ઉપરની નિર્ભરતાઓ છે

ગેટવે ઉપરના માઉન્ટ માટે VPN પર અને ફાઇલસિસ્ટમ માટે ઉપરના સર્વર પર નિર્ભર છે. હજુ ચાલતી સ્થાનિક નિકાસ પ્રક્રિયા અનુપલબ્ધ સંગ્રહને સ્વસ્થ બનાવી શકતી નથી. શરૂઆતનો ક્રમ, પુનઃકનેક્શન વર્તન અને સર્વર પુનઃપ્રારંભનું આયોજન કરો, જેમાં ક્લાયન્ટ પાસે પહેલેથી રહેલા ફાઇલહેન્ડલનું શું થશે તેનો સમાવેશ થાય છે. જે ક્લાયન્ટે ગેટવે દ્વારા માઉન્ટ કર્યું અને તેનું હેન્ડલ ગુમાવ્યું તેને ફરી માઉન્ટની જરૂર છે, અને તે ઓપરેશનલ ઘટના છે, પારદર્શક પુનઃપ્રાપ્તિ નહીં.

જો જરૂરિયાતને ક્યારેય ફક્ત ખાનગી IP પહોંચની જરૂર હતી, તો મૂળ સર્વર પર સીધું રાઉટિંગ સરળ આર્કિટેક્ચર છે. ફરી-નિકાસ એવા કારણ માટે હોવી જોઈએ જે લખાયા પછી ટકી રહે.

કાર્યભારની કસોટી કરો, માઉન્ટની નહીં

નિયંત્રિત વાતાવરણમાં વાસ્તવિક ફાઇલ કાર્યભારનો અભ્યાસ કરો: એપ્લિકેશન જે કામગીરી કરે છે, જે ફાઇલ કદ વાપરે છે અને જે સમવર્તીતાની અપેક્ષા રાખે છે. ફક્ત પરિવહન ભૂલો નહીં, સુવિધાના અંતરાલો પર ધ્યાન આપો. પછી નોંધો કે તમે કયું મોડેલ પસંદ કર્યું અને કેમ, કારણ કે નહીં તો આગલી વ્યક્તિ ધારશે કે ગેટવે રાઉટર છે.

ફરી-નિકાસ ત્યારે વૈધ છે જ્યારે તે જાણીતા કારણ માટે અસ્તિત્વમાં હોય, જેમ કે અલગ ક્લાયન્ટ નેટવર્ક અથવા નિયંત્રિત આવૃત્તિ સીમા. તે ખરાબ અકસ્માત છે, અને તફાવત એ છે કે કોઈએ તે નક્કી કર્યું છે કે નહીં.