New York VPS hosting বাছার আগে যা জানা জরুরি

একটি New York VPS আসলে আপনাকে কী দেয়

New York VPS যুক্তরাষ্ট্রের পূর্ব উপকূলের দুটি বড় interconnection market-এর একটিতে অবস্থিত। অন্যটি হলো Virginia-এর Ashburn। আপনি যা পান, তা হলো Boston থেকে Washington পর্যন্ত বিস্তৃত অঞ্চলের ব্যবহারকারীদের জন্য স্বল্প round-trip latency এবং North America থেকে Europe-এ যাওয়ার সবচেয়ে সংক্ষিপ্ত fiber path। আপনার ব্যবহারকারীরা যদি পুরো মহাদেশে প্রায় সমানভাবে ছড়িয়ে থাকেন, তাহলে একটি কেন্দ্রীয় location সাধারণত তাদের জন্য ভালো service দেয়। এই দুটি পরিস্থিতির মধ্যে পার্থক্য নির্ধারণ করতে অনুমান নয়, measurement প্রয়োজন।

কেন New York VPS hosting মূলত New Jersey hosting

Manhattan-এ carrier hotel-গুলো অবস্থিত। 60 Hudson Street সবচেয়ে পরিচিত ভবন: Tribeca-তে অবস্থিত এই Art Deco ভবনটি 1930 সালে নির্মিত হয়। এতে 300-এর বেশি carrier ও cloud provider এবং অঞ্চলটির network exchange রয়েছে, যার মধ্যে DE-CIX New York ও NYIIX অন্তর্ভুক্ত। কয়েক ব্লক দূরে 32 Avenue of the Americas একই কাজ করে। New Jersey পাশে 165 Halsey Street in Newark তার সমতুল্য।

Network-গুলো পরস্পরের সঙ্গে যেখানে সংযুক্ত হয়, সেই ভবনগুলো সেখানেই। বেশি পরিমাণ compute সেখানে থাকে না, কারণ Manhattan-এ power ও floor space ব্যয়বহুল এবং সম্প্রসারণ করা কঠিন। বড় data hall Hudson নদীর ওপারে Secaucus, Weehawken, Carteret, Piscataway ও Newark-এ অবস্থিত। কোনো provider যখন "New York" VPS বিক্রি করে, তখন প্রায় সব ক্ষেত্রেই Midtown থেকে প্রায় 40 km দূরের ওই বলয়ের কোনো একটি rack বোঝায়। অতিরিক্ত fiber latency এক millisecond-এরও কম বাড়ায়, তাই web workload এটি বুঝতে পারবে না। নির্দিষ্ট কোনো network-এর সঙ্গে cross-connect প্রয়োজন হলেই শুধু কোন building-এ service চলছে তা জিজ্ঞাসা করুন।

এই মহানগর অঞ্চলে এত capacity কেন গড়ে উঠল

চারটি কারণ রয়েছে। প্রতিটি কারণ অন্যগুলোকেও আরও শক্তিশালী করেছে।

• Transatlantic cable এখানকার পাশেই land করে। New Jersey উপকূলের Wall Township এবং Manasquan দেশের সবচেয়ে ব্যস্ত cluster। AEC-2 নামে বিক্রি হওয়া Havfrue Wall থেকে Denmark-এর Blaabjerg পর্যন্ত গেছে এবং এর branch Ireland ও Norway-এ পৌঁছেছে। Seabras-1 একই station থেকে Brazil পর্যন্ত গেছে, আর TGN Atlantic Europe-এর সঙ্গে সংযোগ স্থাপন করেছে। Apollo England-এর Bude এবং France-এর Lannion থেকে Manasquan-এ shore-এ উঠে এসেছে। Google's Grace Hopper cable Long Island-এর Bellport-এ land করে এবং September 2022 থেকে Bude-এ traffic বহন করছে।
• Exchange-গুলো Wall Street ছেড়ে গেছে। NYSE matching engine Mahwah-এ, Nasdaq-এরটি Carteret-এ এবং Cboe-এরটি Secaucus-এ চলে। Trader-রা এই site-গুলোকে equity triangle বলেন। যেসব firm-এর microseconds-এর মধ্যে market data প্রয়োজন, তাদের কোনো একটি site-এর পাশে space নিতে হয়। এই চাহিদাই এমন fiber-এর খরচ দিয়েছে, যা এখন আমরা সবাই share করি।
• Media এবং advertising এখানেই রয়েছে। একটি real-time bidding auction-কে page loading শেষ হওয়ার আগেই answer দিতে হয়। তাই ad exchange-গুলো তাদের agency network-এর পাশে গড়ে উঠেছে, যাদের কাছে তারা বিক্রি করে।
• Network সাধারণত যেখানে আগে থেকেই network রয়েছে, সেখানেই যায়। একবার কোনো building-এ কয়েকশ carrier space share করলে, নতুন carrier-এর জন্য অন্য কোথাও infrastructure তৈরি করার বদলে তাদের সঙ্গে যুক্ত হয়ে সস্তায় transit এবং ভালো peering পাওয়া যায়।

VPS buyer-এর জন্য এসবের কোনোটিই prestige-এর বিষয় নয়। এর অর্থ হলো transit provider-দের মধ্যে প্রতিযোগিতা বেশি, peering ঘন, এবং Europe-এর দিকে path ছোট—কারণ path-টি cable যেখান থেকে শুরু হয়, সেখান থেকেই শুরু হয়।

একটি round trip-এর প্রকৃত খরচ

কাচের ভেতর আলো প্রতি সেকেন্ডে প্রায় 200,000 km বেগে চলে। এটি vacuum-এর আলোর গতির প্রায় দুই-তৃতীয়াংশ। Router packet-এ কাজ করার আগেই fiber-এর প্রতি 100 km-এ round-trip time 1 ms যোগ হয়। Fiber সরলরেখায় চলে না। এটি right of way এবং সমুদ্রতলের route অনুসরণ করে। তাই বাস্তব path-এর দৈর্ঘ্য map distance-এর চেয়ে বেশি হয়।

খরচ একটি round trip-এর নয়। আপনার protocol-এর প্রয়োজনীয় round trip-এর সংখ্যাই মোট খরচ নির্ধারণ করে। নতুন HTTPS connection-এ TCP (transmission control protocol) handshake-এর জন্য একটি round trip লাগে। TLS (transport layer security) 1.3 handshake-এর জন্য আরও একটি লাগে। Request পাঠিয়ে প্রথম byte ফেরত পেতেও আরও একটি লাগে। 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
  }
]

এই column-গুলোর মান measurement নয়, arithmetic থেকে পাওয়া। first byte-এর ক্ষেত্রে তিনটি round trip ধরা হয়েছে। chain column-এ এমন একটি page বোঝানো হয়েছে, যা পরপর ছয়টি dependent API call চালায়। 5 ms-এর metro network-এর মধ্যে connection setup-এর সময় বোঝা যায় না। Atlantic পেরিয়ে 78 ms হলে একই page প্রথম HTML byte পাওয়ার আগে 234 ms অপেক্ষা করে। ছয়টি call-এর chain শুধু অপেক্ষা করতেই 468 ms ব্যয় করে। New York থেকে Singapore পর্যন্ত 230 ms হলে ওই chain-এর খরচ 1380 ms।

Server সরানোর আগে chain column দেখুন। Connection reuse এবং TLS session resumption বারবার হওয়া অতিরিক্ত round trip বাদ দেয়। ছয়টি dependent call-এর পরিবর্তে দুটি parallel call করলে server-কে একটি মহাদেশের কাছে সরানোর চেয়ে বেশি সময় সাশ্রয় হয়। Round trip কমানোর আর কোনো উপায় না থাকলে server সরান। উদাহরণ হিসেবে login বা এমন database write, যা client batch করতে পারে না।

New York metro VPS থেকে সাধারণ round trip time

[
  {
    "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
  }
]

এগুলো কোনো নির্দিষ্ট মেশিন থেকে নেওয়া পরিমাপ নয়; প্রকাশিত সাধারণ পরিসংখ্যান হিসেবে দেখুন। সাধারণ transit ব্যবহার করা ভালোভাবে সংযুক্ত host-গুলোর জন্য এগুলো প্রচলিতভাবে উদ্ধৃত পরিসর। আপনার নিজের network path-এ মান এই পরিসরের যেকোনো পাশে হতে পারে। Ashburn-এর দূরত্ব প্রায় 8 ms। এটি যথেষ্ট কাছাকাছি, তাই New York VPS বাস্তব কোনো latency penalty ছাড়াই Virginia cluster-এর service-গুলোতে request পাঠাতে পারে। Toronto-এর দূরত্ব প্রায় 14 ms। London-এর latency প্রায় 78 ms এবং Frankfurt-এর প্রায় 88 ms। এ কারণেই east coast-এর একটি server ইউরোপীয় ব্যবহারকারীদের জন্য গ্রহণযোগ্য কর্মক্ষমতা দিতে পারে, কিন্তু west coast-এর একটি server তা পারে না।

পূর্ব উপকূলে অবস্থান বেছে নেওয়া উপযুক্ত যখন

• আপনার অধিকাংশ ব্যবহারকারী Boston থেকে Washington পর্যন্ত করিডোরে অবস্থান করেন। এই অঞ্চলে United States-এর Internet চাহিদার বড় একটি অংশ রয়েছে, এবং পুরো এলাকাটি metro থেকে কয়েক মিলিসেকেন্ড দূরে।
• আপনি একটি machine থেকে eastern United States এবং Europe-এ service দেন। New York সবচেয়ে কম খরচের সমঝোতা, কারণ transatlantic সংযোগের পথ এখান থেকেই শুরু হয়।
• আপনি metro-তে আগে থেকেই থাকা কোনো ব্যবস্থার ওপর নির্ভর করেন: Secaucus বা Ashburn-এর market data feed, ad exchange অথবা partner API।
• আপনি Canada-তে hosting না করেও সেখানে পৌঁছানোর সংক্ষিপ্ত network path চান। Toronto প্রায় 14 ms দূরে। Canadian data residency বাধ্যতামূলক হলে সেটি আলাদা সিদ্ধান্ত, এবং Canadian VPS hosting বেছে নেওয়ার সময় আসলে যা গুরুত্বপূর্ণ বিষয়টি ব্যাখ্যা করে।

যখন কেন্দ্রীয় US location East Coast-এর চেয়ে ভালো

গড় পরিস্থিতির বদলে worst case ধরে নকশা করুন। দূরের coast-এর একজন user latency টের পাবেন। পাশের state-এর একজন user তা টের পাবেন না।

[
  {
    "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 দূরে। তাই সারা দেশজুড়ে এর worst case New York-এর প্রায় অর্ধেক। আপনার traffic map যদি সত্যিই national হয়, তাহলে এটিই শক্তিশালী অবস্থান। Dallas-এ VPS রাখার পক্ষে যুক্তি-তে এই market বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে। Chicago-ও আরেকটি যুক্তিসঙ্গত মধ্যবর্তী location, তবে এটি East-এর দিকে বেশি ঝুঁকে আছে।

আরও দুটি পরিস্থিতি New York-এর বদলে অন্য location বেছে নেওয়ার পক্ষে যায়। আপনার user-রা যদি Ontario বা Quebec-এ কেন্দ্রীভূত থাকে, তাহলে একটি Toronto VPS তাদের সরাসরি serve করবে। এতে New York থেকে 14 ms hop যোগ হবে না। আপনার প্রায় সব traffic যদি নিজের server-গুলোর মধ্যেই চলাচল করে, তাহলে সেগুলো একই region-এ রাখুন এবং geography নিয়ে ভাবা বন্ধ করুন। কারণ cross-region hop user-দের কাছাকাছি থাকার ফলে পাওয়া যেকোনো সুবিধাকে ছাপিয়ে যাবে।

পরিমাপ করুন, marketing map-এর ওপর নির্ভর করবেন না

Coverage map কোনো building কোথায় আছে তা জানায়। কিন্তু packet কীভাবে সেই building-এ পৌঁছায়, তা জানায় না। এই পথ distance নয়, transit contract এবং peering agreement নির্ধারণ করে। তাই আপনার users যেখানে আছেন, সেখান থেকে পরিমাপ করুন। Home broadband-এ থাকা একটি laptop, VPS-এর চেয়ে ভালো probe। কারণ VPS network-এর ভালো দিকটিতে থাকে।

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

সাধারণ round trip দিয়ে শুরু করুন। চারটির বদলে twentyটি probe পাঠান। hostname-এর জায়গায় নিজের server-এর hostname বসান।

ping -c 20 your-server.example.com

শেষ line-এ rtt min/avg/max/mdev দেখানো হয়। সেখানে average সবচেয়ে কম উপযোগী সংখ্যা। mdev হলো jitter। Average স্বাভাবিক দেখালেও বেশি jitter voice এবং interactive session নষ্ট করে। Wired path-এ zero-এর বেশি packet loss হলে সেটি noise নয়, fault।

এরপর latency কোথায় হচ্ছে তা নির্ধারণ করুন।

mtr -rwzbc 100 your-server.example.com

mtr প্রতিটি hop-এ 100টি probe পাঠায় এবং প্রতি hop-এর loss ও latency দেখায়। -z AS (autonomous system) number যোগ করে, যাতে বোঝা যায় কোন network প্রতিটি hop পরিচালনা করছে। কোনো middle hop-এ loss দেখা গেলেও পরের hop-গুলোতে তা না থাকলে সেটি প্রকৃত loss নয়। ওই router নিজে তৈরি করা ICMP reply rate-limit করছে। এতে আপনার traffic-এর কোনো ক্ষতি হয় না। কোনো hop থেকে শুরু হয়ে পরের প্রতিটি hop-এ চলতে থাকা loss প্রকৃত loss।

Web service বিচার করার জন্য ICMP-ও সঠিক protocol নয়। অনেক network এটিকে low priority দেয়। আপনি যে service সত্যিই দিচ্ছেন, সেটির timing পরিমাপ করুন।

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/

প্রতিটি value শুরু থেকে cumulative seconds হিসেবে দেওয়া হয়। তাই পড়ার সময় subtraction করতে হবে। time_connect থেকে time_namelookup বাদ দিলে একটি round trip পাওয়া যায়। time_appconnect থেকে time_connect বাদ দিলে TLS handshake-এর সময় পাওয়া যায়। time_starttransfer থেকে time_appconnect বাদ দিলে আরও একটি round trip এবং application-এর উত্তর দিতে যত সময় লেগেছে, তা পাওয়া যায়। শেষ subtraction-টিই diagnosis দেয়। এটি যদি একটি round trip-এর কাছাকাছি হয়, তবে network সীমাবদ্ধতা তৈরি করছে এবং কাছের server ব্যবহার করলে উপকার হবে। এটি যদি round trip-এর কয়েক গুণ হয়, তবে application ধীর। Server সরালেও কোনো পরিবর্তন হবে না।

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'

একটি location নির্বাচন করার আগে প্রতিটি candidate location-এর trial instance-এর বিরুদ্ধে একই test চালান। VPS benchmark করার সম্পূর্ণ পদ্ধতি-এ network-এর পাশাপাশি disk এবং CPU-ও পরিমাপ করা হয়েছে। তাই শুধু latency দেখে নির্বাচন করতে হবে না।

New York ঠিকানা নিলে আর কী পরিবর্তন হয়

দামের বিষয়টিই প্রথমে আসে। New York metro-তে বিদ্যুৎ ও floor space-এর খরচ Texas বা Midwest-এর তুলনায় বেশি। কিছু provider এটি প্রতি-location surcharge হিসেবে গ্রাহকের ওপর দেয়। অন্যরা পুরো fleet জুড়ে গড় করে। August 2026 পর্যন্ত এ বিষয়ে কোনো একক নিয়ম নেই। তাই অতিরিক্ত খরচ আছে ধরে নেওয়ার আগে provider-এর নিজস্ব order page-এ দুটি location-এ একই specification-এর দাম দেখুন। প্রতি মাসে VPS-এর প্রকৃত খরচ বিলের বাকি অংশ ব্যাখ্যা করে।

আইন server-এর অবস্থান অনুসরণ করে না। New York-এর SHIELD Act New York-এর কোনো বাসিন্দার private information সংরক্ষণকারী যেকোনো পক্ষের ওপর breach notification এবং reasonable safeguard-এর দায়িত্ব আরোপ করে, সেই data যেখানেই থাকুক। আপনার server Dallas-এ সরিয়ে নিলে এই দায়িত্ব দূর হয় না। আবার Manhattan-এ সরিয়ে নিলেও নতুন করে এই দায়িত্ব তৈরি হয় না। GDPR (general data protection regulation) এবং আপনার European user-দের ক্ষেত্রেও একই কথা প্রযোজ্য। কোনো contract বা sector rule-এ নির্দিষ্ট country-এর কথা উল্লেখ থাকলে location গুরুত্বপূর্ণ হয়ে ওঠে। Healthcare এবং কিছু financial service-এ এটি সাধারণ ঘটনা।

Power এবং flood risk নিয়ে আলাদা করে বলা দরকার। October 2012-এ Hurricane Sandy আঘাত হানার সময় Lower Manhattan-এর কয়েকটি carrier building service হারায়। কারণ basement-এর fuel pump-এ flood হয়েছিল এবং উপরের তলায় থাকা generator-গুলোর fuel শেষ হয়ে গিয়েছিল। যেকোনো metro-তে একটি মাত্র site থাকা মানে একটি single point of failure থাকা। Backup অন্য power grid-এ রাখুন। অন্তত একবার অন্য কোনো স্থানে restore করে দেখুন, যাতে নিশ্চিত হতে পারেন যে restore কাজ করে।

FAQ

ইউরোপীয় ব্যবহারকারীদের জন্য New York VPS কি কেন্দ্রীয় US VPS-এর চেয়ে দ্রুত?

হ্যাঁ, এবং পার্থক্যটি অনুমানযোগ্য। New York metro থেকে London-এর দূরত্ব প্রায় 78 ms, কারণ transatlantic cable-গুলো New Jersey coast এবং Long Island-এ shore-এ ওঠে। Dallas-এর একটি server প্রথমে east coast-এ পৌঁছায় এবং তারপর London-এ যায়। তাই New York পর্যন্ত Dallas-এর প্রায় 38 ms network round trip অতিরিক্ত যোগ হয়। একটি machine-কে eastern United States এবং Europe—দুই অঞ্চলই serve করতে হলে New York সবচেয়ে কম latency-র compromise।

আমার "New York" VPS আসলে New Jersey-তে কেন?

কারণ সেখানে rack-এর জন্য floor space এবং পর্যাপ্ত power আছে। 60 Hudson Street-এর মতো Manhattan building মূলত interconnection hub, বড় compute hall নয়। তাই rack-গুলো Secaucus, Weehawken, Carteret, Piscataway বা Newark-এ থাকে। অতিরিক্ত fiber-এর কারণে latency well under one millisecond বাড়ে, যা কোনো web workload-এ বোঝা যায় না। নির্দিষ্ট কোনো building-এর ভেতরে নির্দিষ্ট network-এর সঙ্গে cross-connect প্রয়োজন হলেই শুধু exact facility-এর নাম জিজ্ঞেস করুন।

latency আসলেই আমার সমস্যার কারণ কি না কীভাবে বুঝব?

curl timing breakdown চালিয়ে latency-গুলো বাদ দিন। time_appconnect এবং time_starttransfer-এর মধ্যকার পার্থক্য হলো একটি network round trip এবং আপনার server-এর নিজস্ব processing time। সেই পার্থক্য ping দিয়ে মাপা round trip-এর চেয়ে অনেক বেশি হলে delay আপনার application-এর ভেতরে হচ্ছে। কাছের data center ব্যবহার করলে তখন সমস্যার সমাধান হবে না। পার্থক্যটি যদি প্রায় একটি round trip-এর সমান হয়, কিন্তু page এখনও ধীর মনে হয়, তাহলে page-টি ধারাবাহিকভাবে কতগুলো request পাঠায় তা গণনা করুন। কারণ প্রতিটি request-এর জন্য আবার একটি round trip লাগে।

New York-এ hosting করলে আমার ওপর প্রযোজ্য privacy law কি বদলে যায়?

সাধারণত না। New York-এর SHIELD Act এবং GDPR-এর মতো বিধি নির্ভর করে আপনি কার data সংরক্ষণ করছেন তার ওপর, disk কোথায় চলছে তার ওপর নয়। কোনো contract বা sector-specific rule নির্দিষ্ট দেশের নাম উল্লেখ করলে server location গুরুত্বপূর্ণ হয়ে ওঠে। Healthcare এবং financial services-এর কিছু অংশে এটি প্রায়ই ঘটে। কোনো location বেছে নেওয়ার আগে প্রকৃত requirement পড়ুন।

ভালোভাবে স্থাপন করা VPS-এর পরিবর্তে কি CDN ব্যবহার করা যায়?

Static file-এর ক্ষেত্রে যায়। CDN (content delivery network) আপনার ব্যবহারকারীদের কাছাকাছি image এবং script cache করে এবং এসব request-এর জন্য দূরত্বজনিত latency কমিয়ে দেয়। Logged-in dashboard বা database-এ write request cache করা যায় না। তাই সেগুলো এখনও origin server-এ যায় এবং পুরো network round trip-এর latency বহন করে। Data write করা ব্যবহারকারীদের কাছাকাছি origin রাখুন এবং বাকি request CDN-কে পরিচালনা করতে দিন।