New York VPS ஹோஸ்டிங் தேர்வு செய்வது எப்படி?

New York VPS உங்களுக்கு உண்மையில் என்ன வழங்குகிறது

New York VPS என்பது அமெரிக்காவின் கிழக்குக் கடற்கரையில் உள்ள இரண்டு பெரிய interconnection சந்தைகளில் ஒன்றில் அமைந்துள்ளது. மற்றொன்று Virginia-வில் உள்ள Ashburn ஆகும். நீங்கள் வாங்குவது Boston மற்றும் Washington-க்கு இடைப்பட்ட பயனர்களுக்குக் குறுகிய round trip நேரத்தையும், வட அமெரிக்காவிலிருந்து ஐரோப்பாவிற்குச் செல்லும் மிகக் குறுகிய fiber பாதையையும் ஆகும். உங்கள் பயனர்கள் கண்டம் முழுவதும் சமமாகப் பரவியிருந்தால், ஒரு மையப்பகுதி அவர்களுக்குச் சிறந்த சேவையை வழங்கும். இந்த இரண்டு சூழல்களுக்கும் உள்ள வித்தியாசத்தைக் கண்டறிவது என்பது யூகத்தின் அடிப்படையில் அல்ல, அளவீட்டின் அடிப்படையில் இருக்க வேண்டும்.

New York VPS hosting ஏன் பெரும்பாலும் New Jersey hosting ஆக உள்ளது

Manhattan-ல் தான் carrier hotels அமைந்துள்ளன. 60 Hudson Street என்பது இதில் மிகவும் புகழ்பெற்றது: இது 1930-ல் கட்டி முடிக்கப்பட்ட Tribeca-வில் உள்ள ஒரு Art Deco கட்டிடமாகும். இதில் 300-க்கும் மேற்பட்ட carriers மற்றும் cloud providers உள்ளனர். மேலும், DE-CIX New York மற்றும் NYIIX உள்ளிட்ட இப்பகுதிக்கான exchanges-ம் இங்குதான் உள்ளன. 32 Avenue of the Americas-ம் சில blocks தள்ளி இதே பணியைச் செய்கிறது. New Jersey பகுதியில் 165 Halsey Street, Newark இதே போன்ற முக்கியத்துவத்தைக் கொண்டுள்ளது.

இந்தக் கட்டிடங்களில்தான் networks ஒன்றையொன்று சந்திக்கின்றன. ஆனால், அதிகப்படியான compute வசதிகள் இங்கு இருப்பதில்லை. ஏனெனில், Manhattan-ல் மின்சாரம் மற்றும் இடவசதிக்கான செலவு அதிகம், மேலும் அவற்றை விரிவாக்குவதும் கடினம். பெரிய server halls அனைத்தும் Hudson ஆற்றின் மறுபுறம் Secaucus, Weehawken, Carteret, Piscataway மற்றும் Newark ஆகிய இடங்களில் அமைந்துள்ளன. "New York" VPS என்று விற்கும் ஒரு provider, பெரும்பாலும் Midtown-லிருந்து 40 km சுற்றளவுக்குள் உள்ள அந்த வளையத்தில் ஏதோ ஒரு rack-ஐயே குறிப்பிடுகிறார். கூடுதல் fiber இணைப்பிற்கான காலதாமதம் ஒரு millisecond-க்கும் மிகக் குறைவு என்பதால், web workload-ல் இது எந்த மாற்றத்தையும் ஏற்படுத்தாது. ஒரு குறிப்பிட்ட network-உடன் cross-connect தேவைப்பட்டால் மட்டுமே, அது எந்தக் கட்டிடம் என்று கேட்டுத் தெரிந்துகொள்ளுங்கள்.

இந்த மெட்ரோ பகுதியில் கொள்ளளவு (capacity) ஈர்க்கப்பட்டது எப்படி

நான்கு காரணங்கள் உள்ளன, ஒவ்வொன்றும் மற்றொன்றின் வலிமையை அதிகரிக்கின்றன.

• அட்லாண்டிக் கடலுக்கடியிலான கேபிள்கள் அருகிலேயே தரை இறங்குகின்றன. நியூ ஜெர்சி கடற்கரையில் உள்ள Wall Township மற்றும் Manasquan ஆகியவை நாட்டின் மிக முக்கியமான மையங்களாகும். AEC-2 என்று அழைக்கப்படும் Havfrue, Wall-லிருந்து டென்மார்க்கின் Blaabjerg வரை செல்கிறது, மேலும் அயர்லாந்து மற்றும் நார்வேக்கு கிளைகளைக் கொண்டுள்ளது. Seabras-1 அதே நிலையத்திலிருந்து பிரேசிலுக்குச் செல்கிறது, TGN Atlantic ஐரோப்பாவிற்குச் செல்கிறது. Apollo கேபிள் இங்கிலாந்தின் Bude மற்றும் பிரான்சின் Lannion-லிருந்து Manasquan-க்கு வருகிறது. கூகுளின் Grace Hopper கேபிள் லாங் ஐலேண்டின் Bellport-ல் தரை இறங்குகிறது; இது செப்டம்பர் 2022 முதல் Bude-க்கு டிராஃபிக்கைக் கொண்டு செல்கிறது.
• பரிமாற்றகங்கள் (exchanges) Wall Street-ஐ விட்டு வெளியேறின. NYSE மேட்சிங் என்ஜின் Mahwah-விலும், Nasdaq-ன் என்ஜின் Carteret-லும், Cboe-ன் என்ஜின் Secaucus-லும் இயங்குகின்றன. வர்த்தகர்கள் இந்த இடங்களை 'ஈக்விட்டி முக்கோணம்' (equity triangle) என்று அழைக்கிறார்கள். மைக்ரோ செகண்டுகளுக்குள் சந்தை தரவு தேவைப்படும் நிறுவனங்கள், இந்த இடங்களில் ஒன்றின் அருகில் இடத்தை வாங்க வேண்டும். அந்தத் தேவையே நாம் இப்போது பயன்படுத்தும் ஃபைபர் இணைப்புகளுக்கான செலவை ஈடுகட்டியது.
• ஊடகம் மற்றும் விளம்பர நிறுவனங்கள் இங்கு உள்ளன. ஒரு பக்கம் லோட் ஆவதற்கு முன்பே நிகழ்நேர ஏல (real-time bidding) முடிவுகள் கிடைக்க வேண்டும். எனவே, விளம்பரப் பரிமாற்றகங்கள் தாங்கள் சேவை வழங்கும் ஏஜென்சி நெட்வொர்க்குகளுக்கு அருகிலேயே கட்டப்பட்டுள்ளன.
• நெட்வொர்க்குகள் ஏற்கனவே உள்ள இடங்களையே நாடுகின்றன. பல நூறு கேரியர்கள் ஒரே கட்டிடத்தைப் பகிரும்போது, வேறு எங்கும் புதியதாகக் கட்டுவதை விட, அவர்களுடன் இணைவதன் மூலம் மலிவான டிரான்சிட் மற்றும் சிறந்த பியரிங் (peering) கிடைக்கிறது.

ஒரு VPS வாங்குபவருக்கு, இதில் கௌரவம் முக்கியமல்ல. இதன் பொருள், டிரான்சிட் போட்டித்தன்மை கொண்டது, பியரிங் அடர்த்தியானது, மற்றும் ஐரோப்பாவிற்கான பாதை கேபிள்கள் தொடங்கும் இடத்திலேயே அமைந்திருப்பதால் அது மிகக் குறுகியது.

ஒரு round trip-ன் உண்மையான செலவு

கண்ணாடி இழைக்குள் ஒளி வினாடிக்கு சுமார் 200,000 கி.மீ வேகத்தில் பயணிக்கிறது, இது வெற்றிடத்தில் அதன் வேகத்தில் மூன்றில் இரண்டு பங்கு ஆகும். எந்தவொரு router-ம் packet-ஐத் தொடுவதற்கு முன்பே, ஒவ்வொரு 100 கி.மீ fiber நீளத்திற்கும் 1 ms round-trip நேரம் செலவாகிறது. fiber பாதைகள் நேர்க்கோட்டில் இல்லாமல், நில உரிமைகள் மற்றும் கடல்வழிப் பாதைகளைப் பின்பற்றுவதால், உண்மையான தூரம் வரைபடத் தூரத்தை விட அதிகமாக இருக்கும்.

இதற்கான செலவு என்பது ஒரு round trip மட்டுமல்ல. உங்கள் protocol-க்குத் தேவைப்படும் மொத்த round trip-களின் எண்ணிக்கையே ஆகும். ஒரு புதிய HTTPS connection, TCP (transmission control protocol) handshake-க்கு ஒரு round trip-ஐயும், TLS (transport layer security) 1.3 handshake-க்கு இன்னொன்றையும், request-ஐ அனுப்பி முதல் bytes-ஐப் பெறுவதற்கு மற்றொன்றையும் செலவிடுகிறது. browser-க்கு HTML தெரிவதற்கு முன்பே மொத்தம் மூன்று round trip-கள் முடிந்துவிடுகின்றன. TLS 1.2 பயன்படுத்தினால் நான்காவது round trip-ம் சேரும்.

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

அந்தக் கட்டங்கள் அளவீடுகளை விடக் கணக்கீடுகளையே காட்டுகின்றன: முதல் byte-க்கு மூன்று round trip-கள் தேவைப்படுகின்றன, மேலும் chain கட்டம் என்பது ஒன்றன்பின் ஒன்றாக ஆறு API அழைப்புகளைச் செய்யும் ஒரு பக்கத்தைக் குறிக்கிறது. 5 ms கொண்ட metro பகுதிக்குள், connection setup கண்ணுக்குத் தெரிவதில்லை. அட்லாண்டிக் கடலுக்கு அப்பால் 78 ms வேகத்தில், அதே பக்கம் HTML-ன் முதல் byte-க்காக 234 ms காத்திருக்கிறது, மேலும் அந்த ஆறு அழைப்புகளைக் கொண்ட chain, காத்திருப்பதற்கே 468 ms செலவிடுகிறது. நியூயார்க்கிலிருந்து சிங்கப்பூருக்கு 230 ms வேகத்தில், அந்த chain-க்கு 1380 ms செலவாகிறது.

server-ஐ மாற்றுவதற்கு முன் chain கட்டத்தைப் படியுங்கள். Connection reuse மற்றும் TLS session resumption ஆகியவை நீங்கள் மீண்டும் மீண்டும் செலுத்தும் round trip செலவுகளைக் குறைக்கின்றன. ஒன்றையொன்று சார்ந்திருக்கும் ஆறு அழைப்புகளை இரண்டு parallel அழைப்புகளாக மாற்றுவது, server-ஐ ஒரு கண்டத்திற்கு அருகில் நகர்த்துவதை விட அதிக நேரத்தைச் சேமிக்கும். round trip-களைக் குறைக்க முடியாத சூழலில் மட்டும் server-ஐ இடமாற்றம் செய்யுங்கள்: உதாரணமாக, login அல்லது உங்கள் client-ஆல் batch செய்ய முடியாத database write போன்ற நேரங்களில் மட்டும் இதைச் செய்யவும்.

New York மெட்ரோ VPS-லிருந்து பொதுவான round trip நேரங்கள்

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

இவற்றை ஏதேனும் ஒரு குறிப்பிட்ட machine-ன் அளவீடுகளாகக் கருதாமல், பொதுவாக வெளியிடப்பட்ட தரவுகளாகக் கருதவும். இவை சாதாரண transit-ல் நன்கு இணைக்கப்பட்ட hosts-க்குக் குறிப்பிடப்படும் பொதுவான வரம்புகள்; உங்கள் network path இவற்றின் எந்தப் பக்கத்திலும் அமையலாம். Ashburn சுமார் 8 ms தொலைவில் உள்ளது; இது மிக அருகில் இருப்பதால், New York VPS-ஆல் Virginia cluster-ல் உள்ள சேவைகளை பெரிய பாதிப்பின்றி அழைக்க முடியும். Toronto சுமார் 14 ms தொலைவில் உள்ளது. London சுமார் 78 ms தொலைவிலும், Frankfurt சுமார் 88 ms தொலைவிலும் உள்ளன. இதனால்தான், ஒரு east coast server-ஆல் ஐரோப்பிய பயனர்களுக்குச் சிறப்பாகச் சேவை வழங்க முடிகிறது, ஆனால் west coast server-ஆல் அவ்வாறு செய்ய முடிவதில்லை.

East Coast-ல் server அமைப்பது எப்போது சரியான முடிவு

• உங்கள் பயனர்களில் பெரும்பாலோர் Boston முதல் Washington வரையிலான பகுதியில் உள்ளனர். அமெரிக்காவின் இணையத் தேவையில் பெரும் பகுதியை இந்தப் பகுதி கொண்டுள்ளது, மேலும் இப்பகுதியின் அனைத்து இடங்களும் இந்த மெட்ரோ நகரங்களிலிருந்து சில மில்லி விநாடி தூரத்தில் மட்டுமே உள்ளன.
• நீங்கள் அமெரிக்காவின் கிழக்கு பகுதி மற்றும் ஐரோப்பாவிற்கு ஒரே machine மூலம் சேவை வழங்குகிறீர்கள். transatlantic இணைப்பு இங்கிருந்து தொடங்குவதால், New York மிகவும் சிக்கனமான சமரசமாகும்.
• நீங்கள் ஏற்கனவே அந்த மெட்ரோ பகுதியில் உள்ள ஒரு சேவையைச் சார்ந்துள்ளீர்கள்: சந்தை தரவுத் தகவல் (market data feed), விளம்பரப் பரிமாற்றம் (ad exchange), அல்லது Secaucus அல்லது Ashburn-ல் உள்ள ஒரு partner API.
• நீங்கள் கனடாவில் host செய்யாமலேயே, அங்கிருந்து ஒரு குறுகிய பாதையை விரும்புகிறீர்கள். Toronto-விற்கான தூரம் சுமார் 14 ms ஆகும். கனடிய தரவு இருப்பிடக் கொள்கை (data residency) ஒரு கட்டாயத் தேவையாக இருந்தால், அது வேறுபட்ட முடிவாகும், மேலும் கனடிய VPS hosting-ஐத் தேர்ந்தெடுக்கும்போது கவனிக்க வேண்டியவை அதைப் பற்றி விரிவாக விளக்குகிறது.

மத்திய அமெரிக்க அமைவிடம் கிழக்குக் கடற்கரையை விடச் சிறந்ததாக இருக்கும்போது

சராசரி நிலையை விட மோசமான சூழலைக் கருத்தில் கொண்டு வடிவமைக்கவும். தொலைதூரக் கடற்கரையில் உள்ள பயனர் தாமதத்தை (lag) உணர்வார். அருகில் உள்ள மாநிலத்தில் உள்ள பயனர் அதை உணரமாட்டார்.

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

New York server-க்கும் Los Angeles-க்கும் இடையே உள்ள தூரம் 70 ms ஆகும். Dallas server-க்கும் New York-க்கும் இடையே 38 ms-ம், Los Angeles-க்கும் இடையே 35 ms-ம் உள்ளது. எனவே, நாடு தழுவிய அளவில் அதன் மோசமான தாமத நிலை, New York-ஐ விட பாதியாகவே உள்ளது. உங்கள் traffic வரைபடம் உண்மையாகவே நாடு தழுவியதாக இருக்கும்போது, இதுவே வலுவான நிலையாகும். Dallas-ல் VPS அமைப்பதற்கான காரணங்கள் அந்தச் சந்தையை விரிவாக விளக்குகின்றன. Chicago மற்றொரு பொருத்தமான மையப்பகுதியாகும், ஆனால் அது கிழக்கு நோக்கிச் சாய்ந்துள்ளது.

New York-ஐத் தவிர்ப்பதற்கான மேலும் இரண்டு சூழல்கள் உள்ளன. உங்கள் பயனர்கள் Ontario அல்லது Quebec பகுதிகளில் அதிகமாக இருந்தால், Toronto VPS அவர்களுக்கு நேரடியாகச் சேவை வழங்கும். இது New York-லிருந்து வரும் 14 ms தாமதத்தைத் தவிர்க்கும். உங்கள் traffic அனைத்தும் உங்கள் சொந்த server-களுக்கு இடையே மட்டுமே பரிமாறப்பட்டால், அவற்றை ஒரே பகுதியில் வைத்துக்கொள்ளுங்கள். புவியியல் அமைப்பைப் பற்றிச் சிந்திக்கத் தேவையில்லை, ஏனெனில் பிராந்தியங்களுக்கு இடையிலான hop (cross-region hop), பயனர்களுக்கு அருகில் இருப்பதன் மூலம் கிடைக்கும் நன்மைகளை விட அதிகத் தாமதத்தை ஏற்படுத்தும்.

அளவீடு செய்யுங்கள், சந்தைப்படுத்தல் வரைபடங்களை நம்பாதீர்கள்

ஒரு கவரேஜ் வரைபடம் ஒரு கட்டிடம் எங்கே இருக்கிறது என்பதை மட்டுமே காட்டும். பாக்கெட்டுகள் அந்த கட்டிடத்தை எப்படி அடைகின்றன என்பதை அது சொல்லாது; அந்தப் பாதை தூரத்தினால் அல்ல, மாறாக டிரான்சிட் ஒப்பந்தங்கள் மற்றும் பியரிங் உடன்படிக்கைகளால் தீர்மானிக்கப்படுகிறது. எனவே, உங்கள் பயனர்கள் இருக்கும் இடத்திலிருந்து அளவீடு செய்யுங்கள். நெட்வொர்க்கின் சிறந்த பகுதியில் இருக்கும் VPS-ஐ விட, வீட்டு பிராட்பேண்டில் இணைக்கப்பட்டுள்ள லேப்டாப் ஒரு சிறந்த ஆய்வு கருவியாகும்.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

சாதாரண ரவுண்ட் ட்ரிப் (round trip) சோதனையுடன் தொடங்குங்கள், நான்கு ஆய்வுகளுக்குப் பதிலாக இருபது ஆய்வுகளை அனுப்புங்கள். ஹோஸ்ட்நேமிற்குப் பதிலாக உங்கள் சொந்த சர்வரைப் பயன்படுத்துங்கள்.

ping -c 20 your-server.example.com

கடைசி வரி rtt min/avg/max/mdev-ஐக் காட்டுகிறது. அதில் சராசரி (average) என்பது மிகக் குறைந்த பயனுள்ள எண்ணாகும். mdev என்பது ஜிட்டர் (jitter) ஆகும்; சராசரி சரியாகத் தெரிந்தாலும், அதிக ஜிட்டர் இருந்தால் குரல் மற்றும் ஊடாடும் அமர்வுகள் (interactive sessions) பாதிக்கப்படும். வயர்டு பாதையில், பூஜ்ஜியத்திற்கு மேல் இருக்கும் எந்தவொரு பாக்கெட் இழப்பும் (packet loss) பிழையாகவே கருதப்பட வேண்டும், அது வெறும் இரைச்சல் (noise) அல்ல.

பிறகு, நேரம் எங்கே செலவாகிறது என்பதைக் கண்டறியவும்.

mtr -rwzbc 100 your-server.example.com

mtr ஒவ்வொரு ஹாப் (hop)-க்கும் 100 ஆய்வுகளை அனுப்பி, ஒவ்வொரு ஹாப்பிலும் ஏற்படும் இழப்பு மற்றும் லேட்டன்சியை அச்சிடும். -z என்பது AS (autonomous system) எண்ணைச் சேர்க்கும், இதன் மூலம் எந்த நெட்வொர்க் எந்த ஹாப்பைக் கொண்டுள்ளது என்பதை நீங்கள் பார்க்கலாம். ஒரு இடைப்பட்ட ஹாப்பில் காட்டப்படும் இழப்பு, அடுத்தடுத்த ஹாப்களில் மறைந்துவிட்டால் அது உண்மையான இழப்பு அல்ல: அந்த ரவுட்டர் தான் உருவாக்கும் ICMP பதில்களை ரேட்-லிமிட் (rate-limiting) செய்கிறது, இது உங்கள் டிராஃபிக்கைப் பாதிக்காது. ஒரு ஹாப்பில் தொடங்கி, அதற்குப் பின் வரும் அனைத்து ஹாப்களிலும் தொடரும் இழப்பு மட்டுமே உண்மையானது.

வெப் சர்வீஸை மதிப்பிடுவதற்கு ICMP சரியான புரோட்டோகால் அல்ல, ஏனெனில் பல நெட்வொர்க்குகள் இதற்கு குறைந்த முன்னுரிமையையே அளிக்கின்றன. நீங்கள் உண்மையில் வழங்கும் சேவையை நேரத்தைக் கணக்கிடுங்கள்.

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

ஒவ்வொரு மதிப்பும் தொடக்கத்திலிருந்து திரட்டப்பட்ட வினாடிகள் ஆகும், எனவே இதைப் படிக்க நீங்கள் கழித்தல் செய்ய வேண்டும். time_connect மைனஸ் time_namelookup என்பது ஒரு ரவுண்ட் ட்ரிப் ஆகும். time_appconnect மைனஸ் time_connect என்பது TLS ஹேண்ட்ஷேக் ஆகும். time_starttransfer மைனஸ் time_appconnect என்பது மற்றொரு ரவுண்ட் ட்ரிப் மற்றும் உங்கள் அப்ளிகேஷன் பதிலளிக்க எடுத்துக்கொண்ட நேரம் ஆகும். அந்த கடைசி கழித்தல் தான் நோயறிதல் (diagnosis). அது ஒரு ரவுண்ட் ட்ரிப்பிற்கு அருகில் இருந்தால், நெட்வொர்க் தான் தடையாக உள்ளது, எனவே அருகில் உள்ள சர்வர் உதவும். அது ரவுண்ட் ட்ரிப்பை விட பல மடங்கு அதிகமாக இருந்தால், உங்கள் அப்ளிகேஷன் மெதுவாக உள்ளது, அதை நகர்த்துவதால் எந்த மாற்றமும் இருக்காது.

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

ஒரே ஒரு இடத்தைத் தேர்வு செய்வதற்கு முன், ஒவ்வொரு வேட்பாளர் இடத்திலும் உள்ள ட்ரையல் இன்ஸ்டன்ஸில் அதே சோதனையைச் செய்யுங்கள். VPS-ஐ பெஞ்ச்மார்க் செய்வதற்கான முழுமையான முறை நெட்வொர்க்குடன் சேர்த்து டிஸ்க் மற்றும் CPU-வையும் உள்ளடக்கியது, எனவே நீங்கள் லேட்டன்சியை மட்டும் வைத்து முடிவெடுக்க வேண்டியதில்லை.

New York முகவரியால் வேறு என்ன மாற்றங்கள் ஏற்படும்

விலைதான் முதல் மாற்றம். Texas அல்லது Midwest பகுதிகளை விட New York மெட்ரோ பகுதியில் மின்சாரம் மற்றும் இடவசதிக்கான செலவு அதிகம். சில சேவை வழங்குநர்கள் (providers) இதை அந்தந்த இடத்திற்கான கூடுதல் கட்டணமாக வசூலிக்கிறார்கள், மற்றவர்கள் இதைத் தங்கள் அனைத்து மையங்களுக்கும் பொதுவான சராசரி விலையாக நிர்ணயிக்கிறார்கள். ஆகஸ்ட் 2026 நிலவரப்படி, இதற்கு பொதுவான விதிமுறை ஏதுமில்லை. எனவே, கூடுதல் கட்டணம் இருப்பதாகக் கருதும் முன், சேவை வழங்குநரின் இணையதளத்தில் ஒரே மாதிரியான விவரக்குறிப்புகளுக்கு (specification) இரண்டு வெவ்வேறு இடங்களில் என்ன விலை என்று சரிபார்க்கவும். ஒரு VPS-ன் மாதந்திர உண்மையான செலவு என்பது மீதமுள்ள கட்டண விவரங்களை விளக்குகிறது.

சட்டம் server-ஐப் பின்தொடர்வதில்லை. New York-ன் SHIELD Act, ஒரு New York குடியிருப்பாளரின் தனிப்பட்ட தகவல்களை வைத்திருக்கும் எவரும், அந்தத் தரவு எங்கிருந்தாலும், தரவு கசிவு ஏற்பட்டால் அறிவிக்க வேண்டும் மற்றும் தகுந்த பாதுகாப்பு நடவடிக்கைகளை எடுக்க வேண்டும் என்று கட்டாயப்படுத்துகிறது. உங்கள் server-ஐ Dallas-க்கு மாற்றுவதால் இந்த கடமை நீங்கிவிடாது, அதேபோல் Manhattan-க்கு மாற்றுவதால் புதிதாக இந்த கடமை உருவாகிவிடாது. இது GDPR (general data protection regulation) மற்றும் உங்கள் ஐரோப்பிய பயனர்களுக்கும் பொருந்தும். ஒரு ஒப்பந்தம் அல்லது துறை சார்ந்த விதிமுறை ஒரு குறிப்பிட்ட நாட்டைப் பற்றிக் குறிப்பிடும்போது மட்டுமே இருப்பிடம் முக்கியத்துவம் பெறுகிறது; இது சுகாதாரத் துறை மற்றும் சில நிதிச் சேவைகளில் பொதுவாகக் காணப்படும்.

மின்சாரம் மற்றும் வெள்ள அபாயம் குறித்து ஒரு பத்தி அவசியம். அக்டோபர் 2012-ல் Hurricane Sandy தாக்கியபோது, Lower Manhattan-ல் இருந்த பல carrier கட்டிடங்களில் சேவை முடங்கியது. ஏனெனில், அடித்தளத்தில் இருந்த எரிபொருள் இறைப்பான்கள் (fuel pumps) வெள்ளத்தில் மூழ்கின, மேல் தளத்தில் இருந்த மின்பிறப்பாக்கிகள் (generators) எரிபொருள் தீர்ந்து நின்றன. எந்தவொரு மெட்ரோ பகுதியிலும் ஒரே ஒரு தளம் என்பது ஒற்றைப் புள்ளி தோல்வி (single point of failure) ஆகும். எனவே, வெவ்வேறு மின் கட்டமைப்புகளில் (power grid) காப்புப்பிரதிகளை (backups) வைத்திருங்கள். மேலும், அந்த காப்புப்பிரதி சரியாகச் செயல்படுகிறதா என்பதை உறுதிப்படுத்த, குறைந்தபட்சம் ஒருமுறையாவது வேறொரு இடத்தில் அதை மீட்டு (restore) சரிபார்க்கவும்.

FAQ

ஐரோப்பிய பயனர்களுக்கு மத்திய அமெரிக்க VPS-ஐ விட நியூயார்க் VPS வேகமானதா?

ஆம், இதை ஓரளவிற்கு துல்லியமாக கணிக்க முடியும். நியூயார்க் பெருநகரப் பகுதியிலிருந்து லண்டன் சுமார் 78 ms தொலைவில் உள்ளது, ஏனெனில் அட்லாண்டிக் கடலுக்கடியிலான கேபிள்கள் நியூ ஜெர்சி கடற்கரை மற்றும் லாங் ஐலேண்டில் கரையேறுகின்றன. டல்லாஸில் உள்ள ஒரு server லண்டனை அடைய முதலில் கிழக்கு கடற்கரைக்குச் செல்ல வேண்டும், எனவே டல்லாஸிலிருந்து நியூயார்க் செல்லும் கூடுதல் 38 ms காலதாமதம் அதனுடன் சேரும். ஒரு machine அமெரிக்காவின் கிழக்கு பகுதி மற்றும் ஐரோப்பா ஆகிய இரண்டிற்கும் சேவை வழங்க வேண்டும் என்றால், நியூயார்க் சிறந்த சமரசமாகும்.

எனது "நியூயார்க்" VPS ஏன் உண்மையில் நியூ ஜெர்சியில் உள்ளது?

ஏனெனில் அங்கேதான் போதிய இடவசதியும் மின்சாரமும் உள்ளன. 60 Hudson Street போன்ற மன்ஹாட்டன் கட்டிடங்கள் பெரிய compute halls-ஐ விட interconnection hubs-ஆகவே செயல்படுகின்றன. எனவே, racks அனைத்தும் Secaucus, Weehawken, Carteret, Piscataway அல்லது Newark ஆகிய இடங்களில் உள்ளன. இந்த கூடுதல் fiber இணைப்பு ஒரு மில்லிசெகண்டிற்கும் குறைவான காலதாமதத்தையே ஏற்படுத்தும், இதை எந்தவொரு web workload-லும் உணர முடியாது. ஒரு குறிப்பிட்ட கட்டிடத்திற்குள் இருக்கும் ஒரு குறிப்பிட்ட network-உடன் cross-connect தேவைப்படும்போது மட்டுமே சரியான facility-ஐக் கேட்கவும்.

latency தான் எனது பிரச்சினை என்பதை நான் எப்படி அறிவது?

curl timing breakdown-ஐ இயக்கி, மதிப்புகளைக் கழிக்கவும். time_appconnect மற்றும் time_starttransfer ஆகியவற்றுக்கு இடைப்பட்ட இடைவெளி என்பது ஒரு network round trip மற்றும் உங்கள் server-ன் processing நேரம் ஆகும். இந்த இடைவெளி ping மூலம் நீங்கள் அளந்த round trip-ஐ விட மிக அதிகமாக இருந்தால், தாமதம் உங்கள் application-க்குள் உள்ளது; எனவே அருகில் உள்ள data center-க்கு மாறினாலும் இது சரியாகாது. இடைவெளி ஒரு round trip-க்கு நெருக்கமாக இருந்து, பக்கம் இன்னும் மெதுவாகத் தெரிந்தால், அந்தப் பக்கம் எத்தனை கோரிக்கைகளை வரிசையாக (in sequence) அனுப்புகிறது என்று எண்ணுங்கள், ஏனெனில் ஒவ்வொரு கோரிக்கைக்கும் மீண்டும் ஒரு round trip நேரம் செலவாகும்.

நியூயார்க்கில் hosting செய்வது எனக்குப் பொருந்தும் தனியுரிமைச் சட்டங்களை மாற்றுமா?

பெரும்பாலும் இல்லை. நியூயார்க்கின் SHIELD Act மற்றும் GDPR போன்ற விதிகள், தரவு எங்கு சேமிக்கப்படுகிறது என்பதை விட, யாருடைய தரவை நீங்கள் வைத்திருக்கிறீர்கள் என்பதைப் பொறுத்தே அமையும். ஒரு ஒப்பந்தம் அல்லது துறை சார்ந்த விதி ஒரு குறிப்பிட்ட நாட்டைப் பெயரிட்டுக் குறிப்பிடும்போது மட்டுமே server-ன் இருப்பிடம் முக்கிய காரணியாகிறது; இது பெரும்பாலும் சுகாதாரம் மற்றும் நிதிச் சேவைகளில் நடக்கும். ஒரு இருப்பிடத்தைத் தேர்ந்தெடுப்பதற்கு முன், அந்தத் தேவையை நிறைவேற்றுகிறதா என்பதை உறுதிப்படுத்த அதன் நிபந்தனைகளை வாசிக்கவும்.

ஒரு CDN-ஆல் சரியான இடத்தில் உள்ள VPS-க்கு மாற்றாக இருக்க முடியுமா?

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