પ્રોક્સી VIP ફેલઓવર પછી શું ટકે છે?
પ્રોક્સી પ્રવેશદ્વારની પુનઃપ્રાપ્તિને સ્થાપિત CONNECT ટનલ અને વેબસાઇટ તરફના આઉટબાઉન્ડ સરનામાના ટકી રહેવાથી અલગ કરો.
તરતું સરનામું પ્રોક્સી સેટિંગ સ્થિર રાખે છે: સક્રિય મશીન નિષ્ફળ જાય પછી પણ ક્લાયન્ટ એ જ હોસ્ટનામ કે IP વાપરવાનું ચાલુ રાખે છે. તે ઉપયોગી ઉપલબ્ધતા છે. પણ ચાલુ ડાઉનલોડ તો થંભી પણ શકે છે.
CONNECT ની અંદર પહેલેથી રહેલી HTTPS વિનંતી વિચારો. સક્રિય પ્રોક્સી ક્લાયન્ટ તરફનું TCP કનેક્શન અને વેબસાઇટ તરફનું બીજું કનેક્શન ધરાવે છે. તે એ સ્ટ્રીમને જોડતી એપ્લિકેશન સ્થિતિ પણ ધરાવે છે.
સરનામું સ્ટેન્ડબાય મશીન પર ખસેડવાથી પોતે જ કોઈ TCP નિયંત્રણ બ્લોક કે તે રિલે સ્થિતિ ખસતી નથી. નવો માલિક નવા કનેક્શન સ્વીકારી શકે છે, પણ જૂના માલિકે સ્થાપેલો બાઇટ પ્રવાહ ચાલુ રાખી શકતો નથી.
| અપેક્ષા | સામાન્ય સરનામા ફેલઓવર તે આપે છે? |
|---|---|
| એક રૂપરેખાંકિત પ્રવેશદ્વાર રાખવું | તે જ ઇચ્છિત લાભ છે |
| સ્થાપિત CONNECT પ્રવાહ ચાલુ રાખવો | વધારાની સ્થિતિ-આધારિત યંત્રણા જરૂરી થશે |
| એ જ આઉટબાઉન્ડ જાહેર IP રાખવું | આઉટબાઉન્ડ રૂટિંગ અને NAT પર આધારિત |
| અટકેલી એપ્લિકેશન ક્રિયા સુરક્ષિત રીતે પુનરાવર્તિત કરવી | ક્રિયા અને ક્લાયન્ટ પર આધારિત |
VRRP ચૂંટણી અને સરનામાની માલિકી નક્કી કરે છે. તે પ્રોક્સી પ્રક્રિયા માટે પ્રતિકૃતિ પ્રોટોકોલ નથી. બીજા હાઇ-એવેલેબિલિટી સોફ્ટવેર સાથેની તૈનાતીને પણ એ જ ભેદ જોઈએ, સિવાય કે તે સ્પષ્ટપણે વધુ પૂરું પાડે.
આરોગ્ય તપાસ ખરેખર શું નિરીક્ષણ કરે છે તે તપાસો. પ્રોક્સી સેવા, DNS કે અપસ્ટ્રીમ રૂટ નિષ્ફળ હોવા છતાં મશીન જાહેરાતોનો જવાબ આપી શકે છે. ઊલટું, અતિ સંવેદનશીલ તપાસ બિનજરૂરી સ્વિચ પેદા કરી શકે છે.
ક્લાયન્ટ પુનઃપ્રાપ્તિ પણ મહત્વની છે. નવી બ્રાઉઝર વિનંતી સહેલાઈથી ફરી જોડાઈ શકે; વપરાયેલ બોડી સાથેનું અપલોડ કે નોન-આઇડેમ્પોટેન્ટ API ક્રિયાને એપ્લિકેશન-વિશિષ્ટ સંભાળની જરૂર પડી શકે. ફક્ત સ્ટેન્ડબાય દ્વારા નવી વિનંતી સફળ થઈ એટલે અદૃશ્ય ફેલઓવરનું વચન ન આપો.