Frankfurt-ல் VPS hosting: சிறந்த தேர்வு தானா?

Frankfurt-ல் VPS hosting யாருக்கானது

ஜெர்மனி, பரந்த ஜெர்மன் மொழி பேசும் சந்தை அல்லது ஐரோப்பிய ஒன்றியம் முழுவதும் பயனர்களைக் கொண்ட திட்டங்களுக்கு Frankfurt-ல் உள்ள VPS hosting பொருத்தமானது. ஐரோப்பிய நெட்வொர்க்குகள் சந்திக்கும் மற்றும் traffic-ஐ நேரடியாகப் பரிமாறிக்கொள்ளும் இடங்களில் Frankfurt முதன்மையானது. எனவே, அங்குள்ள ஒரு server கண்டத்தின் பெரும்பாலான பகுதிகளுக்குச் சில பத்து மில்லி விநாடிகளில் சென்றடையும். உங்கள் பயனர்கள் பெரும்பாலும் வட அமெரிக்காவில் இருந்தால், அந்த machine எவ்வளவு வேகமாக இருந்தாலும் அவர்களுக்கு ஐரோப்பிய server மெதுவாகவே இருக்கும். ஏனெனில், தூரம் என்பது tuning மூலம் சரிசெய்ய முடியாத ஒரு அடிப்படைத் தடையாகும்.

ஒரு இடத்தைத் தீர்மானிக்கும்போது இரண்டு தனித்தனி கேள்விகள் உள்ளன; இரண்டையும் குழப்பிக்கொள்வது தவறான முடிவுகளுக்கே வழிவகுக்கும். முதலாவது, உங்கள் பயனர்கள் எங்கே இருக்கிறார்கள் என்பது; இது தூரம் மற்றும் round-trip time தொடர்பான கேள்வி. இரண்டாவது, உங்கள் தரவு எங்கே இருக்க அனுமதிக்கப்படுகிறது என்பது; இது சட்ட மற்றும் ஒப்பந்தம் தொடர்பான கேள்வி. ஐரோப்பிய பார்வையாளர்களுக்கு முதல் கேள்விக்கு Frankfurt வலுவான தீர்வை வழங்குகிறது. இரண்டாவது கேள்விக்கு, இது ஒரு குறிப்பிட்ட சிக்கலை நீக்குமே தவிர, மற்ற எதையும் தீர்க்காது.

பிராங்பேர்ட் (Frankfurt) ஏன் இவ்வளவு சிறந்த இணைப்பு வசதியைக் கொண்டுள்ளது?

பிராங்பேர்ட், DE-CIX (Deutsche Commercial Internet Exchange) எனும் IXP-ஐ (internet exchange point) கொண்டுள்ளது. இது உச்சகட்ட நெட்வொர்க் போக்குவரத்து மற்றும் இணைக்கப்பட்ட நெட்வொர்க்குகளின் எண்ணிக்கையின் அடிப்படையில் உலகின் மிகப்பெரிய IXP-களில் ஒன்றாகும். IXP என்பது ஒரு தரவு மையத்திற்குள் (data centre) உள்ள பகிரப்பட்ட switching fabric ஆகும். இதில் சுயாதீனமான நெட்வொர்க்குகள் தங்களுக்குள் போக்குவரத்தை எடுத்துச் செல்ல பெரிய நெட்வொர்க்குகளுக்குக் கட்டணம் செலுத்துவதற்குப் பதிலாக, நேரடியாக ஒன்றோடொன்று இணைக்கப்படுகின்றன. DE-CIX தனது தற்போதைய போக்குவரத்து புள்ளிவிவரங்களை அதன் சொந்த தளத்தில் வெளியிடுகிறது. அந்த எண்கள் தொடர்ந்து மாறுபடும் என்பதால், ஒரு கட்டுரையில் நகலெடுக்கப்பட்ட புள்ளிவிவரங்களை நம்புவதை விட, அந்தத் தளத்திலேயே நேரடியாகப் பார்ப்பது சிறந்தது.

இதன் நடைமுறை விளைவு என்பது மொத்த அளவைப் பற்றியது அல்ல, பாதைகளைப் பற்றியது. உங்கள் சேவை வழங்குநரின் நெட்வொர்க்கும், உங்கள் பயனரின் ISP-யும் (internet service provider) ஒரே exchange-ல் இணைக்கப்பட்டிருக்கும்போது, அவற்றுக்கு இடையேயான போக்குவரத்து அந்த exchange-ல் ஒரே ஒரு routed hop மூலம் கடந்து செல்கிறது. அவை உள்ளூர் அளவில் peer செய்யப்படாதபோது, போக்குவரத்து அந்த இரண்டையும் உள்ளடக்கிய மூன்றாவது நெட்வொர்க்கை அடைய வேண்டியிருக்கும். அந்த நெட்வொர்க்கின் அருகிலுள்ள handover point வேறொரு நாட்டில் இருக்கலாம். ஆம்ஸ்டர்டாம் அல்லது லண்டன் வழியாக போக்குவரத்தைப் பரிமாறிக்கொள்ளும் இரண்டு ஜெர்மன் நெட்வொர்க்குகள், கூடுதல் தூரத்திற்கான கட்டணத்தை இரு திசைகளிலும் செலுத்த வேண்டியிருக்கும். நெட்வொர்க் பொறியாளர்கள் இதை tromboning என்று அழைக்கிறார்கள். அருகிலுள்ள ஒரு server அதிக தூரத்தில் இருப்பதாகக் காட்டுவதற்கு இதுவே பொதுவான காரணமாகும்.

இதை நீங்கள் ஊகிக்கத் தேவையில்லை, நீங்களே பார்க்கலாம். நீங்கள் கவனத்தில் கொள்ளும் நெட்வொர்க்கிலிருந்து உங்கள் server-க்கு எதிராக mtr-ஐ இயக்கவும், பின்னர் reverse DNS-ல் உள்ள hop பெயர்களைப் படிக்கவும். Router-ன் hostnames பொதுவாக IATA விமான நிலையக் குறியீடுகளைக் கொண்டிருக்கும். எனவே, ஒரு hop பெயரில் fra இருந்தால் அது பிராங்பேர்ட் என்றும், ams இருந்தால் ஆம்ஸ்டர்டாம் என்றும், lhr இருந்தால் லண்டன் என்றும் பொருள். ஜெர்மன் நுகர்வோர் இணைப்பிலிருந்து ஜெர்மன் server-க்குச் செல்லும் பாதையில் இடையில் lhr என்று காட்டப்பட்டால், கூடுதல் மில்லி விநாடிகள் எங்கே செலவாகின்றன என்பதை அது துல்லியமாக உணர்த்துகிறது.

உங்கள் பயனர்களிடமிருந்து Frankfurt எவ்வளவு தொலைவில் உள்ளது?

ஒளியானது வெற்றிடத்தில் செல்லும் வேகத்தில் மூன்றில் இரண்டு பங்கு வேகத்தில், அதாவது வினாடிக்கு சுமார் 200,000 கிலோமீட்டர் வேகத்தில் இழைநார் (fibre) வழியாகப் பயணிக்கிறது. ஒரு சுற்றுப் பயணம் (round trip) அந்தப் பாதையை இருமுறை கடக்கிறது, எனவே d கிலோமீட்டர் தொலைவிற்கு மிக வேகமான சுற்றுப் பயண நேரம் d/100 மில்லி வினாடிகள் ஆகும். இதுவே குறைந்தபட்ச கால அளவு (floor), இதைவிட வேகமான பரிமாற்றம் சாத்தியமில்லை என்பதால் இது ஒரு பயனுள்ள அளவீடு ஆகும்.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

இவை நேர்க்கோட்டுத் தொலைவைக் கொண்டு கணக்கிடப்பட்டவை, நேரடியாக அளவிடப்பட்டவை அல்ல. கடைசி நெடுவரிசையை இயற்பியல் விதிகளின்படி சாத்தியமான மிகச்சிறந்த நிலையாகக் கருதவும். இழைநார்கள் சாலைகள் மற்றும் நதிப் பள்ளத்தாக்குகளைப் பின்பற்றிச் செல்வதாலும், பாதையில் உள்ள ஒவ்வொரு router-ம் சிறிய அளவிலான forwarding மற்றும் queuing தாமதத்தை ஏற்படுத்துவதாலும், உண்மையான அளவீடுகள் பெரும்பாலும் இந்த குறைந்தபட்ச கால அளவை விட 1.5 முதல் 2 மடங்கு வரை அதிகமாக இருக்கும்.

Berlin, Frankfurt-லிருந்து 424 km தொலைவில் உள்ளது, இதன் குறைந்தபட்ச கால அளவு 4.2 ms ஆகும். Madrid 1,419 km தொலைவில் உள்ளது, இதன் குறைந்தபட்ச கால அளவு 14.2 ms ஆகும்; இது இங்கிருந்து ஐரோப்பிய ஒன்றியத்தின் தொலைதூர முனையாகும். New York 6,206 km தொலைவில் உள்ளது, இதன் குறைந்தபட்ச கால அளவு 62.1 ms ஆகும். இதனால்தான் அட்லாண்டிக் கடலுக்கு அப்பால் உள்ள பயனர்களைக் கையாள்வது என்பது ஒரு தொழில்நுட்பச் சீரமைப்பு (tuning) சார்ந்த பிரச்சனை அல்ல, அது ஒரு இடஞ்சார்ந்த (location) முடிவாகும்.

ஒரு பக்கத்தை ஏற்றுவதற்கு மெதுவான round trip எவ்வளவு செலவாகும்?

ஒரு round trip என்பது அரிதாகவே ஒரே ஒரு round trip-ஆக இருக்கும். ஒரு HTTPS இணைப்பைத் திறப்பதற்கு TCP (transmission control protocol) handshake-க்கு ஒரு round trip-ம், TLS (transport layer security) 1.3 handshake-க்கு மற்றொரு round trip-ம் தேவைப்படுகிறது. பதிலின் முதல் byte திரும்புவதற்கு முன்பே, கோரிக்கைக்கு (request) மூன்றாவது round trip தேவைப்படுகிறது. TLS 1.2 பயன்படுத்தினால் நான்காவது round trip-ம் சேரும். ஏற்கனவே cache செய்யப்படாத DNS (domain name system) தேடல், வேறொரு server-க்குச் சென்று வர குறைந்தபட்சம் ஒரு round trip-ஐக் கூடுதலாகச் சேர்க்கும்.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

இங்குள்ள round-trip நெடுவரிசை, Frankfurt server-க்குச் செல்லும் ஒரு சாத்தியமான பாதையைப் பற்றிய அனுமானமாகும். இரண்டாவது நெடுவரிசை அதன் கணக்கீடு: முதல் byte வருவதற்கு முன்பே மூன்று round trip-கள் தேவைப்படுகின்றன. Frankfurt-ல் உள்ள ஒரு பயனர் 15 ms காத்திருக்கிறார். சிங்கப்பூரில் உள்ள ஒரு பயனர், 170 ms round-trip நேரத்துடன், அதே பதிலுக்காக 510 ms காத்திருக்கிறார்; இதற்குள் browser எதையும் வரைந்திருக்காது.

இந்த multiplier-தான் மிக முக்கியமானது. RTT (round-trip time)-ல் ஒவ்வொரு கூடுதல் மில்லி விநாடியும், முதல் byte வருவதற்கு முன்பே சுமார் மூன்று மில்லி விநாடிகளைச் செலவாக்குகிறது; அதன் பிறகும் இந்தச் செலவு தொடர்கிறது. HTML ஒரு stylesheet-ஐக் குறிப்பிடுகிறது, அந்த stylesheet ஒரு font-ஐக் குறிப்பிடுகிறது. இவ்வாறு ஒவ்வொரு கண்டுபிடிப்பும் அதே இணைப்பில் மற்றொரு round trip-ஐ உருவாக்குகிறது. சில நூறு மில்லி விநாடி தூரத்தைச் சேர்ப்பது, உடனடியாகத் தெரிந்த ஒரு பக்கத்தை மெதுவாகத் தெரிய வைக்கிறது. ஆனால், server அதே வேலையை அதே நேரத்தில் தான் செய்கிறது.

இது CDN (content delivery network) சரிசெய்யக்கூடியவற்றின் எல்லையையும் நிர்ணயிக்கிறது. பயனருக்கு அருகில் உள்ள cache-லிருந்து வழங்கப்படும் static கோப்புகள் நீண்ட தூரப் பயணத்தைத் தவிர்க்கின்றன. ஆனால், உங்கள் database-இடம் கேள்வி கேட்க வேண்டிய ஒரு logged-in dashboard-க்கு இது பொருந்தாது: அந்த கோரிக்கை இன்னும் முழு தூரத்தையும் இரண்டு முறை கடக்க வேண்டியிருக்கும். பயனர்கள் login செய்யும் இடத்திற்கு அருகிலேயே origin-ஐ வைப்பது மட்டுமே, எந்த cache-ஆலும் செய்ய முடியாத ஒரு செயலாகும்.

எனது பயனர்கள் இருக்கும் இடத்திலிருந்து இதை எவ்வாறு அளவிடுவது?

நீங்கள் அக்கறை கொள்ளும் நெட்வொர்க்கில் உள்ள ஒரு கணினியிலிருந்து இவற்றை இயக்கவும். நீங்கள் சேவை செய்யும் நாட்டில் உள்ள ஒரு வீடு அல்லது அலுவலக இணைப்பிலிருந்து இயக்குவது சிறந்தது. மற்றொரு தரவு மையத்தில் (data centre) உள்ள சர்வரிலிருந்து அளவிடுவது, அந்தத் தரவு மையத்தின் பாதைகளைப் பற்றிய தகவலை மட்டுமே தரும், உங்கள் பயனர்களைப் பற்றியதல்ல. கீழே உள்ள கட்டளைகள் நீங்கள் நீங்களே இயக்க வேண்டிய உதாரணங்கள்: நீங்கள் அளவிடும் தாமத (latency) புள்ளிவிவரங்கள் மட்டுமே நம்பகமானவை.

ping -c 20 your-server.example.com

சுருக்க வரி rtt min/avg/max/mdev = ... என்று வாசிக்கப்படும். பொதுவான நிலைக்கு avg-ஐயும், பாக்கெட்டுகளுக்கு இடையிலான மாறுபாடான ஜிட்டருக்கு (jitter) mdev-ஐயும் வாசிக்கவும். சாதாரண avg உடன் அதிக mdev இருப்பது, பாதை நிலையற்றது என்பதைக் குறிக்கிறது. இது SSH அல்லது குரல் தொடர்பு போன்ற ஊடாடும் (interactive) பணிகளை, சற்று அதிகமான சராசரி தாமதத்தை விடவும் மோசமாகப் பாதிக்கும்.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r நேரடித் திரைக்குப் பதிலாக ஒரு அறிக்கையை அச்சிடுகிறது, -w நீண்ட ஹோஸ்ட் பெயர்களை அப்படியே வைத்திருக்கிறது, -z ஒவ்வொரு ஹாப்-இன் (hop) AS (autonomous system) எண்ணைக் காட்டுகிறது, மற்றும் -c 50 ஐம்பது சுழற்சிகளை அனுப்புகிறது. ஒரு இடைப்பட்ட ஹாப்பில் மட்டும் இழப்பு காட்டப்பட்டு, இறுதி ஹாப்பில் இழப்பு இல்லை என்றால், அது சாதாரணமானது, பிழையல்ல: பல ரவுட்டர்கள் தாங்களாகவே உருவாக்கும் ICMP பதில்களை ரேட்-லிமிட் (rate-limit) செய்யும், அதே சமயம் மற்ற தரவுகளைச் சரியாகவே அனுப்பும். ஒரு ஹாப்பில் தொடங்கி அதற்குப் பின் வரும் அனைத்து ஹாப்களிலும் தொடரும் இழப்புதான் உண்மையான இழப்பாகும்.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

ஒவ்வொரு புலமும் (field) கோரிக்கை தொடங்கியதிலிருந்து திரட்டப்பட்ட வினாடிகளைக் குறிக்கிறது, எனவே கழித்தல் மூலம் இதைப் புரிந்துகொள்ள வேண்டும். time_namelookup என்பது DNS ஆகும். time_connect-லிருந்து அதைக் கழித்தால் கிடைப்பது TCP ஹேண்ட்ஷேக் (handshake), இது ஒரு ரவுண்ட் ட்ரிப்பிற்கு (round trip) சமமானது. time_appconnect-லிருந்து time_connect-ஐக் கழித்தால் கிடைப்பது TLS ஹேண்ட்ஷேக். time_starttransfer-லிருந்து time_appconnect-ஐக் கழித்தால் கிடைப்பது உங்கள் அப்ளிகேஷனின் செயலாக்க நேரம் மற்றும் ஒரு கூடுதல் ரவுண்ட் ட்ரிப் ஆகும். இடைவெளிகள் சிறியதாக இருந்து, total மட்டும் அதிகமாக இருந்தால், சிக்கல் உங்கள் குறியீட்டில் (code) உள்ளது, நகரத்தில் இல்லை.

தாமதத்திற்குப் பதிலாக த்ரூபுட் (throughput) அளவிட, VPS-ல் iperf3 -s-ஐ இயக்கவும், ஃபயர்வால்-ல் அதன் போர்ட்டைத் திறக்கவும், பின்னர் கிளையண்டிலிருந்து iperf3 -c your-server.example.com -R-ஐ இயக்கி டவுன்லோட் வேகத்தைச் சோதிக்கவும். உங்களிடம் கணினி இல்லாத இடங்களிலிருந்து அளவிட, RIPE Atlas ஐரோப்பா முழுவதும் புரோப்களை (probes) வழங்குகிறது. இரண்டு நெட்வொர்க்குகளை ஒப்பிடுவதற்குப் பதிலாக இரண்டு சர்வர்களை ஒப்பிடும்போது, தற்காலிக எண்களைப் பயன்படுத்தாமல் ஒரு நிலையான முறையைப் பயன்படுத்தவும். அதற்குத்தான் மீண்டும் செய்யக்கூடிய VPS பெஞ்ச்மார்க் பயன்படுகிறது.

Frankfurt-ல் உள்ள ஒரு server எனது திட்டத்தை GDPR விதிகளுக்கு உட்பட்டதாக (compliant) மாற்றுமா?

இல்லை, இதற்கான காரணத்தை மிகத் துல்லியமாகப் புரிந்துகொள்வது அவசியம். நீங்கள் யாருடைய தனிப்பட்ட தரவுகளைக் கையாளுகிறீர்கள் மற்றும் உங்கள் நிறுவனம் எங்கு நிறுவப்பட்டுள்ளது என்பதைப் பொறுத்தே GDPR (General Data Protection Regulation) பொருந்தும்; வன்பொருள் (hardware) எந்த நாட்டில் உள்ளது என்பதைப் பொறுத்தல்ல. ஒரு server-ஐ Frankfurt-க்கு மாற்றுவதால் மட்டும் இணக்கம் (compliance) கிடைத்துவிடாது; அதேபோல் EU-க்கு வெளியே ஒரு server-ஐ இயக்குவதால் மட்டும் அது விதியை மீறுவதாகாது. தரவு சேமிக்கப்படும் இடம் என்பது பல காரணிகளில் ஒன்று மட்டுமே.

EU அல்லது EEA (European Economic Area)-க்குள் hosting செய்வதால், சர்வதேச தரவுப் பரிமாற்றம் (international transfer) தொடர்பான சிக்கல்கள் நீங்கும். EEA-க்கு வெளியே தனிப்பட்ட தரவுகளை அனுப்புவது குறித்து இந்த விதியில் ஒரு முழு அத்தியாயமே உள்ளது. இதற்கு adequacy decision அல்லது standard contractual clauses போன்ற சட்டப்பூர்வமான ஆவணங்கள் தேவைப்படும். Frankfurt-ல் இருக்கும் தரவு வெளியே பரிமாறப்படாததால், அந்த அத்தியாயம் அந்தப் பரிமாற்றத்திற்குப் பொருந்தாது. இது ஒரு உண்மையான எளிமைப்படுத்தல் மற்றும் இந்த வசதியால் கிடைக்கும் பயன் இவ்வளவுதான்.

மற்ற அனைத்துப் பணிகளும் உங்கள் பொறுப்பே. ஒவ்வொரு தரவுச் செயலாக்கத்திற்கும் சட்டப்பூர்வமான அடிப்படை, உங்கள் database-ல் உள்ள நபர்களுக்குத் தரவுகளை அணுகவும் நீக்கவும் உரிமை, நீங்கள் நடைமுறைப்படுத்தும் தரவுத் தக்கவைப்பு வரம்பு (retention limit), அபாயத்திற்கு ஏற்ற பாதுகாப்பு நடவடிக்கைகள் மற்றும் தனிப்பட்ட தரவு மீறல் (data breach) நடந்த 72 மணி நேரத்திற்குள் கண்காணிப்பு ஆணையத்திற்கு அறிக்கை அளித்தல் போன்றவை உங்களுக்குத் தேவை. மேலும், உங்கள் hosting வழங்குநருடன் ஒரு processor agreement தேவை; இது ஜெர்மனியில் Auftragsverarbeitungsvertrag அல்லது AVV என்று அழைக்கப்படுகிறது. Frankfurt-ல் உள்ள server-ஐ EEA-க்கு வெளியே உள்ள ஆதரவுப் பணியாளர்கள் அணுக முடிந்தால், அதுவும் தரவுப் பரிமாற்றமாகக் கருதப்படலாம் என்பதை நினைவில் கொள்க; எனவே, யாருக்கு அணுகல் உள்ளது என்பதைச் சரிபார்க்கவும்.

ஜெர்மனி இதனுடன் கூடுதலாகத் தனது சொந்த விதியையும் கொண்டுள்ளது: கூட்டாட்சி BDSG (Bundesdatenschutzgesetz) இந்த ஒழுங்குமுறையுடன் தேசிய விதிகளையும் சேர்க்கிறது. குறிப்பாக, பணியாளர் தரவு (employee data) தொடர்பான விதிகள் பலரை ஆச்சரியப்படுத்தும். இந்தப் பகுதி பொதுவான தகவலுக்காக மட்டுமே, இது சட்ட ஆலோசனை அல்ல. European Data Protection Board தனது அதிகாரப்பூர்வ வழிகாட்டுதல்களை edpb.europa.eu-ல் வெளியிடுகிறது. உண்மையான விளைவுகளை ஏற்படுத்தக்கூடிய விஷயங்களுக்கு, ஒரு tutorial-ஐ நம்புவதை விட தகுதியான சட்ட ஆலோசகரை அணுகுவதே சிறந்தது.

server-ல் நான் எதை மாற்ற வேண்டும்?

System clock-ஐ UTC (coordinated universal time)-ல் வைத்துக்கொண்டு, உங்கள் application-ல் timestamps-ஐ format செய்யவும். ஜெர்மனியில் daylight saving முறை பின்பற்றப்படுவதால், ஆண்டுக்கு இருமுறை local time ஒரு மணிநேரம் மாறுகிறது; அக்டோபர் இறுதியில் ஒரு மணிநேரம் மீண்டும் வரும். இதனால் local time-ல் எழுதப்படும் logs-ல் அந்த இரவில் இரண்டு முறை 02:30 என்று பதிவாகும், இது வெவ்வேறு பிராந்தியங்களில் உள்ள தரவுகளை ஒப்பிடுவதை கடினமாக்கும். ஒருவேளை நீங்கள் server-ல் local time-ஐயே பயன்படுத்த விரும்பினால், அதைத் தெளிவாக அமைத்துச் சரிபார்க்கவும்:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

இதன் வெளியீடு கோடையில் Time zone: Europe/Berlin (CEST, +0200) என்றும், குளிர்காலத்தில் +0100 என்றும் காட்ட வேண்டும்.

Default C locale-ல் ஜெர்மன் எழுத்துக்கள் தவறாக வரிசைப்படுத்தப்படும், ஏனெனில் C sorting raw bytes-ஐ ஒப்பிடுகிறது. Locale-ஐ உருவாக்கி மாற்றத்தைக் கவனிக்கவும்:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

முதல் வரிசைப்படுத்தலில் Äpfel என்பது Zebra-க்கு பின் வரும், ஏனெனில் UTF-8-ல் அதன் முதல் byte எந்தவொரு ASCII எழுத்தை விடவும் பெரியது. இரண்டாவது வரிசைப்படுத்தல் அதை Apfel-க்கு அருகில் வைக்கும், இதுவே ஜெர்மன் வாசகர்கள் எதிர்பார்க்கும் முறை. இது பார்ப்பதை விட முக்கியமானது, ஏனெனில் PostgreSQL மற்றும் MySQL தரவுத்தளத்தை உருவாக்கும்போதே collation-ஐ நிர்ணயித்துவிடும்; பிறகு மாற்றினால் indexes-ஐ மீண்டும் உருவாக்க வேண்டியிருக்கும். தரவுகளை ஏற்றுவதற்கு முன்பே இதை முடிவு செய்யவும்.

ஜெர்மன் package mirror apt பதிவிறக்கங்களை வேகப்படுத்தும். Ubuntu 24.04-ல் sources /etc/apt/sources.list.d/ubuntu.sources கோப்பில் deb822 format-ல் இருக்கும், எனவே இரண்டாவது கோப்பை உருவாக்குவதற்குப் பதிலாக URIs: வரியை http://de.archive.ubuntu.com/ubuntu/ என்று மாற்றவும். புதிய கோப்பை உருவாக்கினால் Target Packages ... is configured multiple times பிழை வரும், இது deb822 duplicate sources error-ஐ உண்டாக்கி, நீங்கள் அதைச் சரிசெய்யும் வரை updates-ஐ நிறுத்திவிடும்.

AAAA record-ஐ வெளியிடவும். சில ஜெர்மன் ISPs வாடிக்கையாளர்களுக்கு DS-Lite (dual-stack lite) இணைப்பை வழங்குகின்றன; இதில் வாடிக்கையாளருக்கு public IPv4 முகவரி இருக்காது, அவர்களின் IPv4 traffic carrier-ன் translation gateway வழியாகச் செல்லும். அந்த gateway தாமதத்தை (latency) உண்டாக்கும் மற்றும் நெரிசலான நேரங்களில் வேகம் குறையும், ஆனால் IPv6 traffic நேரடியாகச் செல்லும். record-ஐ அமைத்த பிறகு இரண்டு வழிகளையும் சரிபார்க்கவும்:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

இரண்டாவது கட்டளையிலிருந்து 200 கிடைத்தால், IPv6 முழுமையாகச் செயல்படுகிறது என்று அர்த்தம். Could not resolve host அல்லது இணைப்புப் பிழை வந்தால், record அல்லது listener விடுபட்டுள்ளது என்று பொருள்; இதனால் உங்கள் DS-Lite பயனர்கள் மெதுவான பாதையைப் பயன்படுத்துவார்கள்.

Frankfurt சரியான தேர்வாக இல்லாதபோது

• உங்கள் பயனர்கள் அமெரிக்காவில் இருந்தால், அங்கிருந்தே சேவைகளை வழங்கவும்: Dallas-ல் உள்ள ஒரு VPS நாட்டின் மையப்பகுதிக்கு அருகில் உள்ளது, மேலும் New York-ல் உள்ள VPS hosting கிழக்கு கடற்கரைக்கும், அட்லாண்டிக் கடலைக் கடந்து வரும் traffic-க்கும் குறுகிய பாதையாக அமையும்.
• உங்கள் பயனர்கள் லத்தீன் அமெரிக்காவில் இருந்தால், New York-ஐ விட Frankfurt, São Paulo-விலிருந்து தொலைவில் உள்ளது. எனவே, அந்தப் பயனர்களுக்கு Brazil-ல் உள்ள ஒரு VPS என்பதே சரியான தீர்வாகும்.
• உங்கள் தரவு ஐரோப்பிய ஒன்றியத்திற்கு வெளியே உள்ள ஒரு குறிப்பிட்ட நாட்டிற்குள் மட்டுமே இருக்க வேண்டும் என்றால், கனடிய பொதுத்துறை பணிகள் இதற்கு பொதுவான உதாரணமாகும். Canadian VPS hosting-க்கு முக்கியமானவை என்பது அங்குள்ள தரவு இருப்பிடம் (residency) குறித்த விவரங்களை விளக்குகிறது.
• நீங்கள் ஒரு game server-ஐ இயக்குகிறீர்கள் என்றால், round-trip time-ன் ஒவ்வொரு மில்லிசெகண்டும் வீரர்களுக்குத் தெரியும். எனவே, அவர்களுக்கு அருகாமையில் இருப்பது மற்ற அனைத்து விவரக்குறிப்புகளை விட முக்கியமானது: game servers-க்கு VPS தேர்ந்தெடுப்பது இதைப் பற்றிய வழிகாட்டலை வழங்குகிறது.

பல நாடுகளில் பரவியிருக்கும் ஐரோப்பிய பயனர்களுக்கு, Frankfurt ஒரு பாதுகாப்பான ஒற்றைத் தேர்வாகும். நீங்கள் வளரும்போதும் இது பாதுகாப்பானதாகவே இருக்கும், ஏனெனில் நீங்கள் அடைய வேண்டிய networks ஏற்கனவே அந்த exchange-ல் உள்ளன. நீங்கள் மாறுவதற்கு முன்பும், மாறிய பின்பும் உங்கள் பயனர்கள் இருக்கும் இடத்திலிருந்து அளவீடுகளைச் செய்து, அந்த இரண்டு தரவுகளையும் வைத்துக்கொள்ளுங்கள்.

FAQ

ஐரோப்பா முழுமைக்கும் Frankfurt-ல் உள்ள ஒரு VPS போதுமானதா?

பெரும்பாலான திட்டங்களுக்கு, ஆம். நேர்க்கோட்டு தூரத்தின் அடிப்படையில் Stockholm-க்கு 12.0 ms மற்றும் Madrid-க்கு 14.2 ms என்ற குறைந்தபட்ச latency உள்ளது. உண்மையான network பாதைகள் இந்த அளவை விட 1.5 முதல் 2 மடங்கு வரை கூடுதலாக இருக்கலாம் என்பதால், ஐரோப்பிய ஒன்றியத்தின் பெரும்பகுதி Frankfurt server-லிருந்து சில மில்லி விநாடிகளிலேயே இணைக்க முடியும். ஒரு குறிப்பிட்ட நாட்டிலிருந்து உண்மையான புகார்கள் வரும்போது அல்லது வேகத்தை விட failover முக்கியம் என்று கருதும்போது மட்டும் இரண்டாவது location-ஐச் சேர்க்கவும்.

Frankfurt-ல் hosting செய்வது எனது திட்டத்தை GDPR விதிகளுக்கு உட்பட்டதாக மாற்றுமா?

இல்லை. நீங்கள் யாருடைய தனிப்பட்ட தரவைச் செயலாக்குகிறீர்கள் மற்றும் உங்கள் நிறுவனம் எங்கு பதிவு செய்யப்பட்டுள்ளது என்பதைப் பொறுத்தே GDPR பொருந்தும்; server எங்குள்ளது என்பது முக்கியமல்ல. ஐரோப்பிய ஒன்றியத்திற்குள் hosting செய்வது அந்தத் தரவுப் பரிமாற்றத்திற்கான சிக்கலை நீக்குகிறது, இது ஒரு நன்மையே. இருப்பினும், உங்களுக்குச் சட்டப்பூர்வ அடிப்படை, தரவு உரிமைகள், தரவு சேமிப்பு வரம்பு, பாதுகாப்பு நடவடிக்கைகள், 72 மணி நேரத்திற்குள் breach reporting மற்றும் உங்கள் provider-உடன் processor agreement (ஜெர்மனியில் AVV என்று அழைக்கப்படும்) ஆகியவை தேவை. இது பொதுவான தகவல் மட்டுமே, சட்ட ஆலோசனை அல்ல.

Frankfurt மற்றும் Berlin இடையே எவ்வளவு latency எதிர்பார்க்கலாம்?

இந்த இரண்டு நகரங்களுக்கு இடையே 424 km தூரம் உள்ளது, இது 4.2 ms என்ற குறைந்தபட்ச round-trip நேரத்தை நிர்ணயிக்கிறது. சரியான peering கொண்ட பாதையில் பொதுவாக அதன் குறைந்தபட்ச அளவை விட 1.5 முதல் 2 மடங்கு latency இருக்கும். Berlin-ல் உள்ள ஒரு இணைப்பிலிருந்து ping -c 20 your-server.example.com மூலம் இதை உறுதிப்படுத்தி, rtt min/avg/max/mdev வரியில் உள்ள avg மதிப்பைச் சரிபார்க்கவும். இந்த வரம்பை விட மிக அதிகமாக இருந்தால், traffic ஜெர்மனிக்கு வெளியே சென்று திரும்புகிறது என்று அர்த்தம்; இதை mtr -rwzc 50 மூலம் hop பெயர்களில் காணலாம்.

எனது Frankfurt server-ன் timezone-ஐ Europe/Berlin என அமைக்க வேண்டுமா?

பொதுவாகத் தேவையில்லை. logs-களை ஒப்பிடுவதற்கும், timestamp-களில் குழப்பம் ஏற்படாமல் இருப்பதற்கும் system-ஐ UTC-லேயே வைத்திருங்கள். ஜெர்மனியில் வசந்த காலத்தில் CEST மற்றும் இலையுதிர் காலத்தில் CET என நேரம் மாறுவதால், இலையுதிர் காலத்தில் ஒரு மணி நேரம் இரண்டு முறை வரும்; இதனால் ஒரே local timestamp-ல் இரண்டு வெவ்வேறு நிகழ்வுகள் பதிவாகலாம். உங்கள் application-ல் local zone-க்கு ஏற்ப நேரத்தை format செய்யுங்கள், அங்குதான் அதைச் சரியாகச் செய்யத் தேவையான சூழல் இருக்கும். ஒருவேளை நீங்கள் முழு server-க்கும் local time அமைக்க விரும்பினால், sudo timedatectl set-timezone Europe/Berlin-ஐ இயக்கி timedatectl மூலம் சரிபார்க்கவும்.

IPv4 மட்டும் கொண்ட server ஜெர்மன் பயனர்களுக்குப் பிரச்சினையாக இருக்குமா?

இது வேலை செய்யும், ஆனால் சில பயனர்களுக்கு வேகம் குறைவாக இருக்கும். பல ஜெர்மன் ISP-கள் நுகர்வோர் இணைப்புகளுக்கு public IPv4 முகவரி இல்லாத DS-Lite அமைப்பையே வழங்குகின்றன. எனவே, அந்தப் பயனர்கள் carrier-ன் translation gateway வழியாகவே IPv4-only server-ஐ அடைய முடியும், இது latency-ஐ அதிகரித்து, நெரிசலான நேரங்களில் வேகம் குறைய வழிவகுக்கும். AAAA record-ஐப் பதிப்பித்து IPv6-ல் listening செய்வதன் மூலம் அவர்களுக்கு நேரடிப் பாதையை வழங்கலாம். இதை dig AAAA your-server.example.com +short மற்றும் curl -6 request மூலம் சோதிக்கவும்; இரண்டு address family-களிலிருந்தும் HTTP 200 கிடைப்பதை உறுதி செய்யவும்.