Dallas VPS Hosting: এতে আপনি কী পান?

আপনি Dallas-এ VPS hosting নিলে যা পান

Dallas-এ VPS hosting আপনাকে একটি নির্দিষ্ট network position দেয়। VPS (virtual private server) হলো একটি নির্দিষ্ট ভবনে থাকা physical machine-এর একটি অংশ। তাই ওই ভবন আপনার ব্যবহারকারীদের কাছে round-trip time, bandwidth-এর মূল্য এবং কোন আদালত আপনার disk-এ আইনি প্রবেশাধিকার পেতে পারে তা নির্ধারণ করে। Dallas যুক্তরাষ্ট্রের প্রায় কেন্দ্রে অবস্থিত এবং দেশের অন্যতম ঘন carrier market-এর মধ্যে পড়ে। Dallas বেছে নেওয়ার মূল কারণ এটিই। এই guide-এর বাকি অংশে দেখানো হবে, এই কারণটি আপনার ব্যবহারকারীদের ক্ষেত্রে প্রযোজ্য কি না এবং কখন এটি প্রযোজ্য নয়।

আপনি যদি এখনো server-টি কী কাজে ব্যবহার করবেন তা নির্ধারণ না করে থাকেন, আগে VPS দিয়ে বাস্তবে কী করা যায় পড়ুন। Location হলো শেষের সিদ্ধান্ত, প্রথমটি নয়।

Dallas VPS থেকে কত latency আশা করা যায়?

[
  {
    "label": "Dallas metro",
    "typical_rtt_ms": 2
  },
  {
    "label": "Houston",
    "typical_rtt_ms": 8
  },
  {
    "label": "Chicago",
    "typical_rtt_ms": 23
  },
  {
    "label": "Miami",
    "typical_rtt_ms": 33
  },
  {
    "label": "New York",
    "typical_rtt_ms": 36
  },
  {
    "label": "Los Angeles",
    "typical_rtt_ms": 35
  },
  {
    "label": "Seattle",
    "typical_rtt_ms": 50
  },
  {
    "label": "Mexico City",
    "typical_rtt_ms": 48
  },
  {
    "label": "Bogota",
    "typical_rtt_ms": 78
  },
  {
    "label": "Sao Paulo",
    "typical_rtt_ms": 140
  },
  {
    "label": "London",
    "typical_rtt_ms": 112
  },
  {
    "label": "Frankfurt",
    "typical_rtt_ms": 125
  },
  {
    "label": "Singapore",
    "typical_rtt_ms": 215
  }
]

এই 13টি সারি ভালো peering-যুক্ত পথে wired connection-এর জন্য প্রকাশিত সাধারণ পরিসংখ্যান। এগুলো আপনার মেশিন থেকে নেওয়া measurement নয়। এগুলোকে প্রাথমিক ধারণা হিসেবে ব্যবহার করুন। আপনার ফলাফল server-এর চেয়ে Internet provider-এর ওপর বেশি নির্ভর করে: Wi-Fi কয়েক মিলিসেকেন্ড latency যোগ করে, mobile network কয়েক দশক মিলিসেকেন্ড যোগ করে, আর peering দুর্বল এমন residential provider এমন পথে 30 ms যোগ করতে পারে, যে পথে physics অনুযায়ী 15 ms হওয়ার কথা।

একটি নির্দিষ্ট সংখ্যার বদলে সামগ্রিক pattern দেখুন। continental United States-এর প্রতিটি বড় শহরে latency প্রায় 50 ms বা তার কম। Houston-এ এটি 8 ms এবং Chicago-তে 23 ms। Mexico City-তে এটি প্রায় 48 ms, যা US-এর যেকোনো উপকূলের চেয়ে কাছাকাছি। কারণ Latin American network traffic-এর বড় অংশ আগে থেকেই Texas বা Florida হয়ে যায়। Sao Paulo-তে 140 ms একটি দীর্ঘ পথ নির্দেশ করে। Singapore-এ 215 ms সম্পূর্ণ ভিন্ন ধরনের সমস্যা।

একটি connection একাধিক round trip নিয়ে গঠিত বলে milliseconds-এর প্রভাব raw figure-এর চেয়ে বেশি। একটি HTTPS request শুরু করতে TCP (transmission control protocol) handshake-এর জন্য এক round trip, TLS 1.3 (transport layer security)-এর জন্য আরও এক round trip এবং request পাঠানোর জন্য আরও এক round trip লাগে। 35 ms latency হলে প্রথম byte আসার আগেই 100 ms-এর বেশি সময় চলে যায়। কোনো page যদি ধারাবাহিকভাবে 20টি API call করে, তাহলে 35 ms latency অপেক্ষার সময়কে 700 ms-এ নিয়ে যায়। 35 ms latency-তে interactive SSH, 8 ms latency-র তুলনায় আলাদা অনুভূত হয়। 35 ms latency-তে game server ব্যবহারযোগ্য থাকে, কিন্তু একই server-এ 140 ms latency গ্রহণযোগ্য নয়। VPS-এ একটি Minecraft server-এর মতো যে বিষয়টি সব user একসঙ্গে অনুভব করেন, সেখানে ভৌগোলিকভাবে কেন্দ্রীয় অবস্থান বাস্তব সুবিধা দেয়।

দেশের মাঝামাঝি অঞ্চল কি উপকূলের চেয়ে ভালো?

ফাইবারে আলো প্রতি সেকেন্ডে প্রায় 200,000 km বেগে চলে। এটি vacuum-এ আলোর গতির দুই-তৃতীয়াংশ। তাই fiber-এর প্রতি 100 km দূরত্বে round trip-এর জন্য প্রায় 1 ms latency যোগ হয়। তাছাড়া fiber কখনও দুই শহরের মধ্যে সরলরেখায় চলে না। এটি physics নির্ধারিত একটি ন্যূনতম সীমা। তাই যত অর্থই খরচ করা হোক, glass যে সীমা নির্ধারণ করে তার চেয়ে দ্রুত Dallas থেকে Frankfurt-এ packet পাঠানো যায় না। আপনার হাতে থাকা একমাত্র কার্যকর উপায় হলো location।

Dallas নিউ ইয়র্ক থেকে প্রায় 2,200 km এবং Los Angeles থেকে প্রায় 2,000 km দূরে। এই দূরত্বের পার্থক্য অস্বাভাবিকভাবে কম। প্রথমে যেসব উপকূলীয় market অধিকাংশ মানুষ বিবেচনা করেন, তাদের সঙ্গে এই পার্থক্য তুলনা করুন।

[
  {
    "label": "Northern Virginia",
    "to_new_york_ms": 10,
    "to_los_angeles_ms": 62
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 36,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Los Angeles metro",
    "to_new_york_ms": 68,
    "to_los_angeles_ms": 3
  }
]

এগুলোও সাধারণত প্রকাশিত figures। তবে মূল বিষয় হলো এই দূরত্বের বিন্যাস। Northern Virginia থেকে নিউ ইয়র্কে পৌঁছাতে প্রায় 10 ms এবং Los Angeles-এ পৌঁছাতে প্রায় 62 ms লাগে। অর্থাৎ পার্থক্য 50 ms-এর বেশি। Los Angeles host-এর ক্ষেত্রে চিত্রটি উল্টো: নিউ ইয়র্কে পৌঁছাতে লাগে 68 ms। যে শহরের পাশে অবস্থিত, সেই শহরের জন্য Dallas উভয়ের চেয়ে ধীর। কিন্তু যে শহর থেকে দূরে অবস্থিত, সেই শহরের জন্য Dallas উভয়ের চেয়ে দ্রুত।

তাই প্রশ্নটি কোন শহর সবচেয়ে দ্রুত, তা নয়। প্রশ্ন হলো আপনি কোন ধরনের দূরত্ব-বিন্যাস চান। আপনার অধিকাংশ user যদি একই উপকূলে থাকেন এবং median latency কম রাখতে চান, তাহলে উপকূল বেছে নিন। আপনার user-রা যদি সারা দেশে ছড়িয়ে থাকেন এবং সবচেয়ে খারাপ অবস্থার latency কম রাখতে চান, তাহলে Dallas বেছে নিন। Canadian VPS বাছাইয়ের সময় আসলে কোন বিষয় গুরুত্বপূর্ণ-এও একই trade-off ব্যাখ্যা করা হয়েছে। সেখানে population দুই উপকূলের বদলে একটি দীর্ঘ রেখা বরাবর বিস্তৃত।

Dallas-এ কোন carrier density বাস্তবে আপনার কাজে আসে

Carrier hotel হলো এমন একটি ভবন, যেখানে অনেক network এসে terminate করে এবং একে অপরের সঙ্গে সরাসরি সংযুক্ত হয়। Dallas-এ এমন একটি পরিচিত স্থাপনা হলো 1950 North Stemmons Freeway-এর Infomart, যা Equinix 2018 সালে $800 million-এ কিনেছিল। Internet exchange (IX) হলো এমন ভবনের ভেতরের একটি shared switch, যেখানে network-গুলো একে অপরের সঙ্গে peer করে। ফলে তাদের মধ্যে traffic পাঠানোর জন্য third party-কে অর্থ দিতে হয় না। DE-CIX November 2016 থেকে Dallas-এ একটি exchange পরিচালনা করছে। Equinix-ও নিজস্ব exchange পরিচালনা করে।

এটি traceroute-এ দেখা যায়। আপনার host এবং আপনার user-এর internet provider একই exchange-এ থাকলে packet একটি boundary অতিক্রম করে। তারা একই exchange-এ না থাকলে packet একটি transit provider-এর কাছে পাঠানো হয়। সেই provider packet-টিকে Ashburn বা Atlanta হয়ে আবার ফিরিয়ে এনে গন্তব্যে পৌঁছে দিতে পারে। অতিরিক্ত দূরত্বের কারণে বাস্তব latency milliseconds-এ বাড়ে। প্রতিটি অতিরিক্ত network এমন একটি সম্ভাব্য bottleneck, যেখানে রাত 9 pm-এ link পূর্ণ হয়ে packet loss হতে পারে।

অর্থ দেওয়ার আগে আপনি এসব যাচাই করতে পারেন।

• Provider-এর কাছে তার ASN (autonomous system number) জানতে চান। BGP (border gateway protocol) ব্যবহারকারী প্রতিটি network-এর একটি ASN থাকে।
• PeeringDB-এ সেই ASN খুঁজুন। সেখানে একটি network কোন কোন exchange-এ যুক্ত এবং কোন কোন ভবনে তার উপস্থিতি আছে, তা দেখানো হয়। Network-গুলো নিজেদের entry নিজেরাই রক্ষণাবেক্ষণ করে।
• Facility-টিতে কোন কোন exchange উপস্থিত আছে, তা পরীক্ষা করুন। কোনো provider exchange-টির একই ভবনে থেকেও সেখানে যুক্ত না থাকলে, এতে আপনার কোনো সুবিধা হবে না।
• আপনার user-রা যে network ব্যবহার করে, সেখান থেকে path trace করুন এবং packet কতগুলো পৃথক network অতিক্রম করে তা গণনা করুন।

mtr -rwzc 100 203.0.113.10

Report-এ প্রতিটি hop-এর জন্য একটি করে line থাকে। সেখানে network number, loss percentage এবং timing দেখানো হয়। প্রথমে শেষ line পড়ুন, কারণ সেটিই আপনার server। মাঝের কোনো hop-এ loss থাকলেও শেষে loss না থাকলে সেটি স্বাভাবিক। কারণ router নিজে তৈরি করা ICMP (internet control message protocol) reply-কে কম priority দেয়। তাই ওই hop-এর loss বাস্তবের চেয়ে বেশি দেখাতে পারে। কোনো hop থেকে শুরু হয়ে পরের প্রতিটি hop-এ loss চলতে থাকলে সেটি বাস্তব fault। Report সংযুক্ত করে support ticket-এ বিষয়টি জানানো উচিত।

Texas-এর বিদ্যুৎ গ্রিড কি আপনার uptime ঝুঁকিতে ফেলছে?

Texas নিজস্ব বিদ্যুৎ গ্রিড পরিচালনা করে। ERCOT (Electric Reliability Council of Texas) রাজ্যের প্রায় 90 percent load সরবরাহ করে এবং North America-এর বাকি অংশের সঙ্গে synchronized নয়। মোটামুটি 1.2 GW ক্ষমতার অল্প কয়েকটি direct current tie-এর মাধ্যমে এটি প্রতিবেশী গ্রিডগুলোর সঙ্গে যুক্ত; বিপরীতে 22 July 2026-এ peak demand 91 GW-এর বেশি রেকর্ড হয়েছিল। তাই Texas-এ বিদ্যুতের ঘাটতি হলে বাইরে থেকে বিদ্যুৎ আমদানি করে পরিস্থিতি সামাল দেওয়া যায় না। February 2021-এর ঘটনাটির পেছনে এই ব্যবস্থাই ছিল, যখন Winter Storm Uri ERCOT জুড়ে কয়েক দিন ধরে পর্যায়ক্রমিক blackout ঘটায়।

আপনার server-এর ক্ষেত্রে মূল প্রশ্ন grid নয়, building। Utility outage হলে data center কয়েক মিনিট UPS (uninterruptible power supply) battery-তে চলে। এরপর fuel থাকা পর্যন্ত diesel generator চালু থাকে। চারটি প্রশ্ন করুন এবং উত্তরগুলো লিখিতভাবে নিন: power path কি N+1 নাকি 2N, সাইটে রাখা fuel দিয়ে full load-এ generator কত ঘণ্টা চলতে পারে, priority fuel delivery contract আছে কি না, এবং শেষবার real load-এ generator পরীক্ষা করা হয়েছিল কবে। কোনো provider শেষ প্রশ্নটির উত্তর দিতে না পারলে ধরে নিন generator পরীক্ষা করা হয়নি।

এই একই grid-এর কারণে এখানে capacity সস্তা। Texas-এ industrial electricity-এর দাম US average-এর নিচে। Data center-এর চলমান খরচের মধ্যে power সবচেয়ে বড়। তাই Dallas-এর দাম northern Virginia-এর মতো constrained market-এর তুলনায় কম। এই পার্থক্য আপনার invoice-এও দেখা যায়। বিভিন্ন শহরের quote তুলনা করার সময় একটি VPS-এর প্রকৃত খরচ কী পাশাপাশি খুলে রাখুন, কারণ base rate-এর পাশে location premium অনেক সহজে বোঝা যায়।

একটি Dallas data center কি tornado এবং Texas-এর তাপের ঝুঁকিতে থাকে?

এই দুটি প্রশ্নের উত্তর আলাদা।

বাতাস ও শিলাবৃষ্টি ভবনের বিষয়। 20 October 2019-এ প্রায় 140 mph বেগের EF3 tornado Dallas Love Field-এর কাছে আঘাত হানে এবং উত্তর Dallas জুড়ে 15 mile দীর্ঘ পথ তৈরি করে। এতে প্রায় $1.5 billion ক্ষয়ক্ষতি হয়। ওই পথ Stemmons Freeway data center corridor থেকে কয়েক mile দূরে। বিশেষভাবে নির্মিত data hall হলো জানালাবিহীন concrete structure। এটি strip mall-এর ছাদ উড়িয়ে নেওয়া বাতাসেও টিকে থাকে। এর উন্মুক্ত অংশগুলো ওপরের দিকে থাকে: condenser এবং cooling tower। প্রায় প্রতি বসন্তেই বড় শিলাবৃষ্টি হয় এবং ঠিক এই equipment-এর ওপর আঘাত করে। Shell কী মাত্রার ঝড় সহ্য করার জন্য rated এবং mechanical plant কোথায় স্থাপন করা হয়েছে, তা জিজ্ঞেস করুন।

তাপ খরচের বিষয়। July এবং August-এ Dallas-এ দীর্ঘ সময় 100 F (38 C)-এর ওপরে তাপমাত্রা থাকে। Cooling স্থানীয় design day অনুযায়ী নির্ধারণ করা হয়, তাই room-এর তাপমাত্রা নিয়ন্ত্রণে থাকে। যা বাড়ে তা হলো PUE (power usage effectiveness, মোট facility power ভাগ করে servers-এ পৌঁছানো power), কারণ February-এর তুলনায় August-এ chiller-গুলোকে বেশি কাজ করতে হয়। এই খরচ আপনার price-এর মধ্যেই থাকে। প্রকৃত তাপের ঝুঁকি হলো heat wave চলাকালে cooling failure: বাইরে তাপমাত্রা 104 F (40 C) থাকলে cooling ছাড়া একটি room এক ঘণ্টার বদলে কয়েক মিনিটের মধ্যেই shutdown temperature-এ পৌঁছে যায়। ফলে chiller মেরামত করার জন্য staff-এর হাতে অনেক কম সময় থাকে। শুধু power আছে কি না নয়, cooling N+1 কি না তা জিজ্ঞেস করুন।

কোনো উত্তরই Dallas এড়িয়ে চলার কারণ নয়। তবে দুটি বিষয়ই আপনার data অন্য কোথাও একটি copy রাখার কারণ। একই building-এ রাখা backup প্রকৃত backup নয়, এবং restic দিয়ে encrypted off site backup সেটআপ করতে একটি বিকেলই যথেষ্ট।

Dallas কখন ভুল পছন্দ?

Dallas একটি যুক্তিসঙ্গত default, তবে এটি বাধ্যতামূলক নিয়ম নয়। নিচের ক্ষেত্রে অন্য স্থানে host করুন।

• আপনার ব্যবহারকারীরা Europe-এ। Dallas-এর server Frankfurt-এ প্রায় 125 ms এবং London-এ প্রায় 112 ms-এ response দেয়। এই পার্থক্য দূরত্বের কারণে, তাই কোনো configuration পরিবর্তন করে এটি কমানো যায় না।
• আপনার ব্যবহারকারীরা Asia বা Australia-এ। Singapore-এ 215 ms latency আরও খারাপ, এবং ওই ব্যবহারকারীদের কাছাকাছি একটি দ্বিতীয় server প্রথম server-এ করা যেকোনো tuning-এর চেয়ে বেশি কার্যকর।
• আপনার সব ব্যবহারকারী Dallas নয়, এমন একটি metro area-তে আছে। আপনার app ব্যবহারকারী সবাই Seattle-এ হলে Seattle-এ host করুন। ব্যবহারকারীদের অবস্থান বিভিন্ন প্রান্তে ছড়িয়ে থাকলেই কেবল কেন্দ্রীয় অবস্থানের সুবিধা পাওয়া যায়।
• কোনো contract বা regulator data একটি নির্দিষ্ট country-তে রাখার বাধ্যবাধকতা দিলে। এটি performance-এর প্রশ্ন নয়, এবং কোনো benchmark এর উত্তর দিতে পারে না।
• কোনো US exchange-এ latency আপনার strategy-এর অংশ হলে। CME Group-এর matching engine Aurora, Illinois-এ। NYSE Mahwah, New Jersey থেকে এবং Nasdaq Carteret, New Jersey থেকে পরিচালিত হয়। Dallas এগুলোর প্রতিটি থেকে 20 ms-এর বেশি দূরে। অধিকাংশ retail automation-এর জন্য এটি গুরুত্বপূর্ণ নয়, এবং trading bot-এর জন্য VPS বেছে নেওয়া কার্যকর হয় latency line বাস্তবে কোথায় পড়ে তার ভিত্তিতে।

ডালাসের সার্ভারে কোন আইন প্রযোজ্য?

ডালাসে থাকা একটি সার্ভার US federal law এবং Texas state law-এর অধীন। প্রতিটি security review-তে দুটি বিষয় উঠে আসে।

US CLOUD Act অনুযায়ী, US কর্তৃপক্ষ কোনো US provider-কে তার নিয়ন্ত্রণাধীন data সরবরাহ করতে বাধ্য করতে পারে, disk শারীরিকভাবে যেখানেই থাকুক। US-এর অন্য কোনো শহর বেছে নিলে এই অবস্থার পরিবর্তন হয় না। সার্ভার US-এর বাইরে রাখলেও provider যদি US company হয়, তাহলে এই আইনের আওতা এড়ানো যায় না।

Texas-এ hosting করলেই আপনি Texas privacy law-এর আওতায় পড়বেন না। TDPSA (Texas Data Privacy and Security Act), যা 1 July 2024 থেকে কার্যকর, এমন business-এর ক্ষেত্রে প্রযোজ্য যা Texas-এ পরিচালিত হয় অথবা Texas residents-দের কাছে কোনো product বা service বিক্রি করে এবং federal Small Business Administration-এর সংজ্ঞা অনুযায়ী small business নয়। এই আইন আপনার customers কোথায়, তা অনুসরণ করে; আপনার rack কোথায়, তা নয়। সার্ভার Chicago-তে সরালেও আপনি exempt হবেন না। আবার Dallas-এ সরালেও আপনি স্বয়ংক্রিয়ভাবে এই আইনের আওতায় পড়বেন না।

European Union থেকে আসা personal data-এর ক্ষেত্রে transfer mechanism থাকলে US hosting অনুমোদিত। August 2026 অনুযায়ী, EU to US Data Privacy Framework-এর adequacy decision কার্যকর রয়েছে। September 2025-এ EU General Court এই সিদ্ধান্ত বহাল রাখে, তবে Court of Justice-এ appeal pending রয়েছে। বাস্তবে আপনার provider-কে লিখিতভাবে জিজ্ঞাসা করুন, provider নিজে ওই framework-এর অধীনে self certifies করে কি না অথবা standard contractual clauses স্বাক্ষর করে কি না। এরপর উত্তরটি এমন স্থানে সংরক্ষণ করুন যেখানে আপনার auditor সহজে তা খুঁজে পাবে। আইনি প্রশ্নটির বাকি অংশ একজন lawyer-এর সঙ্গে আলোচনা করুন, কারণ এই বিষয়টি পরিবর্তনশীল।

নিজের মেশিন থেকে Dallas VPS কীভাবে পরীক্ষা করবেন

উপরের প্রতিটি সংখ্যা অন্য কারও পরিমাপ। সিদ্ধান্ত নেওয়ার জন্য আপনার নিজের পরিমাপই গুরুত্বপূর্ণ, এবং এটি সংগ্রহ করতে প্রায় 20 মিনিট লাগে।

1. Dallas location-এ ব্যবহারের জন্য provider-এর কাছে একটি test IP address এবং একটি test file চান। অধিকাংশ provider দুটিই একটি looking glass page-এ প্রকাশ করে।
2. আপনার ব্যবহারকারীরা যে প্রতিটি network ব্যবহার করেন, সেখান থেকে অন্তত 20টি ping পাঠিয়ে summary line পড়ুন।
3. পথটি trace করুন এবং এটি কতটি network অতিক্রম করে তা গণনা করুন।
4. test file download করে sustained speed পড়ুন।
5. আপনার ব্যবহারকারীদের ব্যস্ত সময়ে, weekday evening-এ, অন্তত 2 দিন এই পরীক্ষা পুনরাবৃত্তি করুন। Congestion 9 pm-এ দেখা যায়, 11 am-এ নয়।

ping -c 20 203.0.113.10
mtr -rwzc 100 203.0.113.10
curl -o /dev/null -s -w 'connect=%{time_connect}s ttfb=%{time_starttransfer}s speed=%{speed_download} B/s\n' "https://<test file host>/100mb.bin"

Windows-এ প্রথম command হলো ping -n 20 203.0.113.10। ping-এর শেষে থাকা summary line-টিই সংরক্ষণ করুন:

rtt min/avg/max/mdev = 34.112/34.905/41.203/0.884 ms

mdev (mean deviation)-কে jitter হিসেবে পড়ুন। গড় 35 ms এবং 2 ms-এর কম mdev একটি স্থিতিশীল path নির্দেশ করে। একই 35 ms গড়ের সঙ্গে 20 ms mdev থাকলে path-এর কোনো অংশ অস্থিতিশীল। Interactive কাজের ক্ষেত্রে এটি স্থির 60 ms-এর চেয়েও খারাপ অনুভূত হবে। Final hop-এ 100টি packet জুড়ে sustained packet loss শূন্যের বেশি হলে সেটি অস্বাভাবিক আচরণ নয়, একটি fault।

Throughput মাপতে আলাদা পরীক্ষা দরকার। দীর্ঘ path-এ একটি TCP connection-এর গতি receive window-কে round trip time দিয়ে ভাগ করার সীমার মধ্যে থাকে। তাই একটি ধীর single-stream download link ধীর—এটি প্রমাণ করে না। এর পরিবর্তে parallel stream ব্যবহার করুন। VPS-এ iperf3 -s চালান এবং port-টি শুধু নিজের address-এর জন্য open করুন। এরপর নিজের machine থেকে চালান:

iperf3 -c 203.0.113.10 -P 4 -t 30
iperf3 -c 203.0.113.10 -P 4 -t 30 -R

-P 4 চারটি parallel stream চালু করে, আর -R direction উল্টে দেয়। তাই দ্বিতীয় run-টি আপনার ব্যবহারকারীরা বাস্তবে যে download path ব্যবহার করবেন, তা মাপে। কাজ শেষ হলে port-টি আবার বন্ধ করুন, কারণ iperf3-এ কোনো authentication নেই।

Network হলো একটি দিক। CPU steal এবং disk speed আলাদা বিষয়। Excellent location-এ থাকা সস্তা plan-ও host machine oversold হলে ধীরে চলে। বাস্তবে কিছু সরানোর আগে VPS কীভাবে benchmark করবেন নির্দেশিকাটি অনুসরণ করুন। এরপর এটি সুরক্ষিত করতে নতুন VPS-এ প্রথম দশ মিনিট সময় দিন।

FAQ

দুই উপকূলের ব্যবহারকারীদের জন্য Dallas-এর একটি VPS কি যথেষ্ট দ্রুত?

হ্যাঁ, real time game এবং latency sensitive trading ছাড়া প্রায় সব কাজের জন্য। Dallas থেকে New York পর্যন্ত wired round trip সাধারণত প্রায় 36 ms এবং Los Angeles পর্যন্ত প্রায় 35 ms, তাই continental United States-এর কোনো ব্যবহারকারীই server থেকে খুব দূরে নয়। New York-এর জন্য northern Virginia-এর server দ্রুততর, প্রায় 10 ms; কিন্তু Los Angeles-এর জন্য এটি অনেক ধীর, প্রায় 62 ms। median latency কমানোর বদলে worst-case latency কম রাখতে চাইলে Dallas বেছে নিন।

Texas-এর power grid কি Dallas VPS-কে কম নির্ভরযোগ্য করে?

ERCOT একটি পৃথক grid। প্রতিবেশী grid-গুলোর সঙ্গে এর direct current সংযোগের ক্ষমতা প্রায় 1.2 GW, তাই power shortage-এর সময় Texas খুব বেশি power আমদানি করতে পারে না। এই কারণে February 2021-এ Winter Storm Uri কয়েক দিন ধরে পর্যায়ক্রমিক blackout ঘটিয়েছিল। আপনার uptime grid-এর চেয়ে building-এর ওপর বেশি নির্ভর করে। UPS battery কয়েক মিনিট load বহন করে, আর diesel generator fuel থাকা পর্যন্ত load চালায়। Provider-এর কাছে site-এ রাখা fuel দিয়ে full load-এ generator কতক্ষণ চলতে পারে এবং সর্বশেষ full load test কবে হয়েছে, তা জিজ্ঞাসা করুন।

Tornado বা Texas-এর heat wave কি আমার server offline করে দেবে?

একা কোনো ঘটনাই সাধারণত তা করবে না। 20 October 2019-এ north Dallas অতিক্রম করা EF3 tornado strip mall ও বাড়িঘর ধ্বংস করেছিল। কিন্তু purpose built data hall সাধারণত জানালাবিহীন concrete structure, যা এমন বাতাসের জন্য তৈরি। ঝুঁকিতে থাকা অংশ হলো rooftop cooling unit; বড় spring hail-ও এগুলোতেই আঘাত করে। Heat uptime-এর চেয়ে খরচ বাড়ায়, কারণ cooling স্থানীয় design day অনুযায়ী নির্ধারিত হয়। তবে heat wave-এর সময় cooling failure হলে কর্মীদের প্রতিক্রিয়া জানানোর সময় অনেক কমে যায়। অন্য region-এ backup রাখুন, কারণ যে ঝুঁকির বিরুদ্ধে design করা যায় না তা হলো পুরো site হারানো।

আমার ব্যবহারকারীরা Europe-এ থাকলে কি Dallas-এ host করা উচিত?

না। Dallas-এর server Frankfurt-এ উত্তর দিতে প্রায় 125 ms এবং London-এ প্রায় 112 ms সময় নেয়। এই পার্থক্য distance-এর কারণে, তাই configuration পরিবর্তন করে তা দূর করা যায় না। ব্যবহারকারীদের কাছাকাছি host করুন। যেসব কাজের জন্য ব্যবহারকারীদের অপেক্ষা করতে হয় না, যেমন backup বা batch job, সেগুলোর জন্য Dallas-এর server রাখতে পারেন। European personal data জড়িত থাকলে EU location ব্যবহার করলে এমন একটি data transfer প্রশ্নও এড়ানো যায়, যা অন্যথায় আপনাকে নথিভুক্ত করতে হতো।

কেনার আগে Dallas VPS-এর latency কীভাবে মাপব?

Provider-এর কাছ থেকে একটি test IP address নিন। এরপর ব্যবহারকারীরা যে প্রতিটি network ব্যবহার করেন, সেখান থেকে সেটির বিরুদ্ধে ping -c 20 এবং mtr -rwzc 100 চালান। ping summary-তে average-এর সঙ্গে mdev value দেখুন। Average কম কিন্তু mdev বেশি হলে jitter আছে; স্থিরভাবে বেশি latency-এর চেয়ে এটি ব্যবহারকারীর কাছে খারাপ অনুভূত হয়। দুই দিন ধরে ব্যবহারকারীদের ব্যস্ত সন্ধ্যার সময়ে পরীক্ষা পুনরাবৃত্তি করুন, কারণ congestion দিনের সময়ের ওপর নির্ভর করে। Throughput মাপতে চারটি parallel stream সহ iperf3 ব্যবহার করুন। দীর্ঘ path-এ একটি TCP stream link-এর সীমার বদলে window size-এর কারণে সীমাবদ্ধ হতে পারে।