ফ্রাঙ্কফুর্টে VPS হোস্টিং কেন সেরা পছন্দ?

ফ্রাঙ্কফুর্টে VPS হোস্টিং কাদের জন্য

ফ্রাঙ্কফুর্টে VPS হোস্টিং সেইসব প্রজেক্টের জন্য উপযুক্ত যাদের ব্যবহারকারীরা জার্মানিতে, বৃহত্তর জার্মান-ভাষী বাজারে অথবা পুরো ইউরোপীয় ইউনিয়ন জুড়ে ছড়িয়ে আছে। ফ্রাঙ্কফুর্ট এমন একটি স্থান যেখানে ইউরোপীয় নেটওয়ার্কগুলো মিলিত হয় এবং সরাসরি একে অপরের কাছে ট্রাফিক আদান-প্রদান করে। তাই সেখানকার একটি সার্ভার থেকে মহাদেশের বেশিরভাগ অংশে মাত্র কয়েক দশ মিলিসেকেন্ডের মধ্যে পৌঁছানো সম্ভব। আপনার ব্যবহারকারীরা যদি মূলত উত্তর আমেরিকায় থাকেন, তবে মেশিন যত দ্রুতই হোক না কেন, ইউরোপীয় সার্ভার তাদের কাছে ধীরগতির মনে হবে। কারণ দূরত্বের কারণে যে ল্যাটেন্সি তৈরি হয়, তা কোনো টিউনিং দিয়েই দূর করা সম্ভব নয়।

দুটি ভিন্ন প্রশ্ন একটি লোকেশন নির্ধারণের সিদ্ধান্তকে প্রভাবিত করে এবং এই দুটিকে গুলিয়ে ফেলাই ভুল সিদ্ধান্তের মূল কারণ। প্রথমটি হলো আপনার ব্যবহারকারীরা কোথায় আছেন, যা মূলত দূরত্ব এবং রাউন্ড-ট্রিপ সময়ের সাথে সম্পর্কিত। দ্বিতীয়টি হলো আপনার ডেটা কোথায় রাখার অনুমতি আছে, যা একটি আইনি এবং চুক্তিভিত্তিক প্রশ্ন। ইউরোপীয় দর্শকদের জন্য প্রথম প্রশ্নের ক্ষেত্রে ফ্রাঙ্কফুর্ট একটি শক্তিশালী সমাধান। দ্বিতীয় প্রশ্নের ক্ষেত্রে এটি একটি নির্দিষ্ট সমস্যার সমাধান করলেও অন্য কোনো আইনি জটিলতা নিরসন করে না।

ফ্রাঙ্কফুর্ট কেন এত ভালোভাবে সংযুক্ত?

ফ্রাঙ্কফুর্টে DE-CIX (Deutsche Commercial Internet Exchange) অবস্থিত, যা একটি IXP (internet exchange point)। এটি পিক ট্রাফিক এবং সংযুক্ত নেটওয়ার্কের সংখ্যার দিক থেকে বিশ্বের অন্যতম বৃহত্তম এক্সচেঞ্জ। IXP হলো ডেটা সেন্টারের ভেতরে থাকা একটি শেয়ারড সুইচিং ফ্যাব্রিক, যেখানে স্বাধীন নেটওয়ার্কগুলো একে অপরের সাথে সরাসরি সংযুক্ত হয়। এর ফলে তাদের ট্রাফিক আদান-প্রদানের জন্য কোনো বড় নেটওয়ার্ককে অর্থ প্রদান করতে হয় না। DE-CIX তাদের বর্তমান ট্রাফিক পরিসংখ্যান তাদের নিজস্ব সাইটে প্রকাশ করে। এই সংখ্যাগুলো পরিবর্তনশীল, তাই কোনো নিবন্ধে কপি করা তথ্যের ওপর নির্ভর না করে সরাসরি সেখান থেকে দেখে নেওয়াই ভালো।

এর ব্যবহারিক প্রভাব মোট ট্রাফিকের ওপর নয়, বরং নেটওয়ার্ক পাথের ওপর পড়ে। যখন আপনার প্রোভাইডারের নেটওয়ার্ক এবং আপনার ভিজিটরের ISP (internet service provider) একই এক্সচেঞ্জে সংযুক্ত থাকে, তখন তাদের মধ্যকার ট্রাফিক সেই এক্সচেঞ্জে মাত্র একটি রাউটেড হপ অতিক্রম করে। যখন তারা স্থানীয়ভাবে পিয়ারিং (peering) করে না, তখন ট্রাফিককে এমন একটি তৃতীয় নেটওয়ার্কে পৌঁছাতে হয় যা উভয়কেই বহন করে। সেই নেটওয়ার্কের নিকটতম হ্যান্ডওভার পয়েন্টটি অন্য কোনো দেশে থাকতে পারে। দুটি জার্মান নেটওয়ার্ক যদি আমস্টারডাম বা লন্ডনের মাধ্যমে ট্রাফিক আদান-প্রদান করে, তবে তাদের অতিরিক্ত দূরত্ব দুইবার অতিক্রম করতে হয়—প্রতিটি দিকে একবার করে। নেটওয়ার্ক ইঞ্জিনিয়াররা একে ট্রাম্বোনিং (tromboning) বলেন, এবং এটিই প্রধান কারণ যার ফলে একটি নিকটবর্তী সার্ভারকেও অনেক দূরে মনে হয়।

আপনি এটি অনুমান না করে সরাসরি দেখতে পারেন। আপনার কাঙ্ক্ষিত নেটওয়ার্ক থেকে আপনার সার্ভারের উদ্দেশ্যে mtr চালান এবং রিভার্স DNS-এ হপের নামগুলো পড়ুন। রাউটারের হোস্টনামে সাধারণত IATA এয়ারপোর্ট কোড থাকে। তাই কোনো হপের নামে fra থাকলে তার অর্থ ফ্রাঙ্কফুর্ট, ams মানে আমস্টারডাম এবং lhr মানে লন্ডন। একটি জার্মান কনজ্যুমার কানেকশন থেকে জার্মান সার্ভারের পথে যদি মাঝখানে lhr দেখা যায়, তবে সেটি আপনাকে স্পষ্টভাবে জানিয়ে দিচ্ছে যে অতিরিক্ত মিলিসেকেন্ডগুলো কোথায় ব্যয় হচ্ছে।

আপনার ব্যবহারকারীদের থেকে ফ্রাঙ্কফুর্ট কত দূরে?

ফাইবার অপটিকের ভেতর দিয়ে আলো শূন্যস্থানের গতির প্রায় দুই-তৃতীয়াংশ বেগে চলে, যা প্রতি সেকেন্ডে প্রায় 200,000 কিলোমিটার। একটি রাউন্ড ট্রিপে পথটি দুইবার অতিক্রম করতে হয়, তাই 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
  }
]

এই মানগুলো সরলরেখার দূরত্বের ভিত্তিতে গণনা করা হয়েছে, পরিমাপ করা নয়। শেষ কলামটিকে পদার্থবিজ্ঞানের অনুমতি অনুযায়ী সেরা পরিস্থিতি হিসেবে বিবেচনা করুন। প্রকৃত পরিমাপ সাধারণত এই সর্বনিম্ন সীমার 1.5 থেকে 2 গুণ হয়ে থাকে, কারণ ফাইবার কেবল গ্রেট সার্কেল অনুসরণ না করে রাস্তা এবং নদীর উপত্যকা ধরে বিছানো থাকে এবং পথের প্রতিটি রাউটার সামান্য ফরওয়ার্ডিং ও কিউইং বিলম্ব যোগ করে।

বার্লিন ফ্রাঙ্কফুর্ট থেকে 424 কিমি দূরে অবস্থিত, যার সর্বনিম্ন সীমা 4.2 ms। মাদ্রিদ 1,419 কিমি দূরে, যার সর্বনিম্ন সীমা 14.2 ms, এবং এটি এখান থেকে ইউরোপীয় ইউনিয়নের দূরতম প্রান্ত। নিউ ইয়র্ক 6,206 কিমি দূরে অবস্থিত, যার সর্বনিম্ন সীমা 62.1 ms। এই কারণেই ট্রান্সআটলান্টিক অডিয়েন্সের বিষয়টি একটি লোকেশন বা স্থান নির্বাচনের সিদ্ধান্ত, কোনো টিউনিং সমস্যা নয়।

একটি ধীরগতির রাউন্ড ট্রিপ পেজ লোডের ওপর কী প্রভাব ফেলে?

একটি রাউন্ড ট্রিপ বলতে সাধারণত একটি রাউন্ড ট্রিপ বোঝায় না। একটি HTTPS কানেকশন খুলতে TCP (transmission control protocol) হ্যান্ডশেকের জন্য একটি রাউন্ড ট্রিপ এবং TLS (transport layer security) 1.3 হ্যান্ডশেকের জন্য আরও একটি রাউন্ড ট্রিপ প্রয়োজন হয়। এরপর রেসপন্সের প্রথম বাইট আসার আগে অনুরোধটির জন্য তৃতীয় একটি রাউন্ড ট্রিপ লাগে। TLS 1.2 এর ক্ষেত্রে চতুর্থ একটি রাউন্ড ট্রিপ যুক্ত হয়। যদি DNS (domain name system) লুকআপ আগে থেকে ক্যাশ করা না থাকে, তবে ভিন্ন একটি সার্ভারের জন্য অন্তত আরও একটি রাউন্ড ট্রিপ যোগ হয়।

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

এখানে রাউন্ড-ট্রিপ কলামটি ফ্রাঙ্কফুর্ট সার্ভারে যাওয়ার একটি সম্ভাব্য পথের অনুমান এবং দ্বিতীয় কলামটি তার গাণিতিক হিসাব: প্রথম বাইট আসার আগে তিনটি রাউন্ড ট্রিপ। ফ্রাঙ্কফুর্টের একজন ব্যবহারকারী 15 ms অপেক্ষা করেন। সিঙ্গাপুরের একজন ব্যবহারকারী, যার রাউন্ড-ট্রিপ সময় 170 ms, তিনি একই রেসপন্সের জন্য 510 ms অপেক্ষা করেন, যার আগে ব্রাউজার কিছুই প্রদর্শন করতে পারে না।

এই গুণকটিই মূল বিষয়। RTT (round-trip time)-এর প্রতিটি অতিরিক্ত মিলিসেকেন্ড প্রথম বাইট আসার আগে প্রায় তিন মিলিসেকেন্ড খরচ বাড়ায় এবং এই খরচ চলতেই থাকে। HTML-এ একটি স্টাইলশিট উল্লেখ থাকে, স্টাইলশিটটি একটি ফন্টের নাম উল্লেখ করে এবং প্রতিটি আবিষ্কারের জন্য একই কানেকশনে আরও একটি রাউন্ড ট্রিপ প্রয়োজন হয়। কয়েকশ মিলিসেকেন্ড দূরত্ব যোগ করলে একটি তাৎক্ষণিক মনে হওয়া পেজ ধীরগতির মনে হতে শুরু করে, যদিও সার্ভার একই সময়ে ঠিক একই কাজ করছে।

এটি CDN (content delivery network) কী সমাধান করতে পারে তার সীমাবদ্ধতাও নির্ধারণ করে। ব্যবহারকারীর কাছাকাছি ক্যাশ থেকে পরিবেশন করা স্ট্যাটিক ফাইলগুলো দীর্ঘ পথ এড়িয়ে যায়। কিন্তু একটি লগ-ইন করা ড্যাশবোর্ড, যাকে আপনার ডাটাবেসকে প্রশ্ন করতে হয়, তা এটি পারে না: সেই অনুরোধটি এখনও পুরো দূরত্ব দুইবার অতিক্রম করে। যারা লগ-ইন করেন তাদের কাছাকাছি অরিজিন সার্ভার রাখা এমন একটি কাজ যা কোনো ক্যাশ আপনার জন্য করে দেয় না।

ব্যবহারকারীরা যেখান থেকে সংযোগ নিচ্ছেন, সেখান থেকে আমি কীভাবে এটি পরিমাপ করব?

আপনার কাঙ্ক্ষিত নেটওয়ার্কের কোনো মেশিন থেকে এগুলো চালান। আদর্শগতভাবে, আপনি যে দেশে সেবা দিচ্ছেন, সেখানকার কোনো বাসা বা অফিসের সংযোগ ব্যবহার করা ভালো। অন্য কোনো ডেটা সেন্টারের সার্ভার থেকে পরিমাপ করলে আপনি কেবল ডেটা সেন্টারের পাথ সম্পর্কে জানতে পারবেন, ব্যবহারকারীদের সংযোগের অবস্থা নয়। নিচের কমান্ডগুলো আপনার নিজের চালানোর জন্য উদাহরণস্বরূপ দেওয়া হলো: শুধুমাত্র আপনার নিজের পরিমাপ করা ল্যাটেন্সি বা বিলম্বের পরিসংখ্যানই কার্যকর।

ping -c 20 your-server.example.com

সারসংক্ষেপের লাইনটি rtt min/avg/max/mdev = ... হিসেবে পড়া হয়। সাধারণ অবস্থার জন্য avg এবং প্যাকেটগুলোর মধ্যে সময়ের তারতম্য বা জিটারের জন্য mdev পড়ুন। একটি স্বাভাবিক avg এর সাথে উচ্চ mdev থাকার অর্থ হলো পাথটি অস্থিতিশীল। এটি সামান্য বেশি গড় ল্যাটেন্সির চেয়েও SSH বা ভয়েস কলের মতো ইন্টারঅ্যাক্টিভ কাজের জন্য বেশি ক্ষতিকর।

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

-r লাইভ ডিসপ্লের পরিবর্তে একটি রিপোর্ট প্রিন্ট করে, -w বড় হোস্টনেমগুলোকে অক্ষুণ্ণ রাখে, -z প্রতিটি হপের AS (অটোনোমাস সিস্টেম) নম্বর দেখায় এবং -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/

প্রতিটি ফিল্ড হলো রিকোয়েস্ট শুরু হওয়ার পর থেকে ক্রমবর্ধমান সেকেন্ড, তাই বিয়োগ করে এর মান বের করতে হয়। time_namelookup হলো DNS। time_connect থেকে এটি বিয়োগ করলে TCP হ্যান্ডশেক পাওয়া যায়, যা প্রায় একটি রাউন্ড ট্রিপের সমান। time_appconnect থেকে time_connect বিয়োগ করলে TLS হ্যান্ডশেক পাওয়া যায়। time_starttransfer থেকে time_appconnect বিয়োগ করলে আপনার অ্যাপ্লিকেশনের নিজস্ব প্রসেসিং সময় এবং আরও একটি রাউন্ড ট্রিপের সময় পাওয়া যায়। যদি এই পার্থক্যগুলো ছোট হয় কিন্তু total বড় থাকে, তবে সমস্যাটি আপনার কোডে, শহরের নেটওয়ার্কে নয়।

থ্রুপুট বা ডেটা স্থানান্তরের হার পরিমাপের জন্য VPS-এ iperf3 -s চালান, ফায়ারওয়ালে এর পোর্টটি ওপেন করুন এবং ক্লায়েন্ট থেকে iperf3 -c your-server.example.com -R চালিয়ে ডাউনলোডের গতি পরীক্ষা করুন। যেসব জায়গায় আপনার কোনো মেশিন নেই সেখান থেকে পরিমাপ করতে, RIPE Atlas আপনাকে পুরো ইউরোপ জুড়ে প্রোব ব্যবহারের সুবিধা দেয়। দুটি নেটওয়ার্কের পরিবর্তে দুটি সার্ভারের তুলনা করার সময় বিচ্ছিন্ন বা একবারের সংখ্যার ওপর নির্ভর না করে একটি নির্দিষ্ট পদ্ধতি ব্যবহার করুন, যার জন্য একটি পুনরাবৃত্তিযোগ্য VPS বেঞ্চমার্ক ব্যবহার করা হয়।

ফ্রাঙ্কফুর্টে সার্ভার থাকলেই কি আমার প্রজেক্ট GDPR কমপ্লায়েন্ট হয়?

না, এবং এর কারণটি স্পষ্টভাবে বোঝা প্রয়োজন। GDPR (General Data Protection Regulation) কার্যকর হয় আপনি কার ব্যক্তিগত ডেটা প্রসেস করছেন এবং আপনার প্রতিষ্ঠান কোথায় অবস্থিত তার ওপর ভিত্তি করে, হার্ডওয়্যারটি কোন দেশে আছে তার ওপর নয়। সার্ভার ফ্রাঙ্কফুর্টে সরিয়ে নিলেই কমপ্লায়েন্স নিশ্চিত হয় না, আবার EU-এর বাইরে সার্ভার চালালেই যে তা স্বয়ংক্রিয়ভাবে নিয়ম ভঙ্গ করে, তাও নয়। সার্ভারের অবস্থান অনেকগুলো বিষয়ের মধ্যে একটি মাত্র।

EU বা EEA (European Economic Area)-এর ভেতরে হোস্টিং করার সুবিধা হলো, এটি আন্তর্জাতিক ডেটা স্থানান্তরের জটিলতা দূর করে। EEA-এর বাইরে ব্যক্তিগত ডেটা পাঠানোর বিষয়ে এই রেগুলেশনে একটি পূর্ণাঙ্গ অধ্যায় রয়েছে, যার জন্য adequacy decision বা standard contractual clauses-এর মতো আইনি কাঠামোর প্রয়োজন হয়। ফ্রাঙ্কফুর্টে থাকা ডেটা স্থানান্তর করা হচ্ছে না, তাই সেই অধ্যায়টি এই ক্ষেত্রে প্রযোজ্য নয়। এটি একটি প্রকৃত সরলীকরণ এবং সুবিধার পরিধি ঠিক এটুকুই।

বাকি সব কাজ আপনাকেই করতে হবে। প্রতিটি উদ্দেশ্যের জন্য আপনার একটি বৈধ ভিত্তি থাকতে হবে, ডেটাবেসে থাকা ব্যক্তিদের জন্য কার্যকর অ্যাক্সেস ও ডিলিট করার অধিকার নিশ্চিত করতে হবে, একটি রিটেনশন লিমিট যা আপনি বাস্তবে প্রয়োগ করেন, ঝুঁকির সাথে সামঞ্জস্যপূর্ণ নিরাপত্তা ব্যবস্থা এবং ব্যক্তিগত ডেটা লঙ্ঘনের (personal data breach) ঘটনা জানার 72 ঘণ্টার মধ্যে সুপারভাইজরি অথরিটিকে রিপোর্ট করার ব্যবস্থা থাকতে হবে। এছাড়া আপনার হোস্টিং প্রোভাইডারের সাথে একটি প্রসেসর এগ্রিমেন্ট থাকতে হবে, যা জার্মানিতে Auftragsverarbeitungsvertrag বা AVV নামে পরিচিত। মনে রাখবেন, ফ্রাঙ্কফুর্টে সার্ভার থাকলেও যদি EEA-এর বাইরের সাপোর্ট স্টাফরা সেটি অ্যাক্সেস করতে পারে, তবে সেটিও ডেটা স্থানান্তর হিসেবে গণ্য হতে পারে, তাই কারা কী অ্যাক্সেস পাচ্ছে তা যাচাই করুন।

জার্মানি এর ওপর নিজস্ব একটি স্তর যোগ করে: ফেডারেল BDSG (Bundesdatenschutzgesetz) জাতীয় নিয়মাবলির মাধ্যমে এই রেগুলেশনকে পরিপূরক করে, এবং কর্মী বা এমপ্লয়ি ডেটার বিষয়টি প্রায়শই মানুষকে অবাক করে। এই অংশটি সাধারণ তথ্যের জন্য, কোনো আইনি পরামর্শ নয়। European Data Protection Board তাদের অফিসিয়াল গাইডলাইন প্রকাশ করে edpb.europa.eu-এ, এবং বাস্তব ফলাফল জড়িত এমন যেকোনো বিষয়ে টিউটোরিয়ালের পরিবর্তে একজন যোগ্য পরামর্শকের সহায়তা নেওয়া উচিত।

সার্ভারে আমার কী পরিবর্তন করা উচিত?

সিস্টেম ক্লক UTC (coordinated universal time)-এ রাখুন এবং আপনার অ্যাপ্লিকেশনে টাইমস্ট্যাম্প ফরম্যাট করুন। জার্মানিতে ডে-লাইট সেভিং অনুসরণ করা হয়, তাই বছরে দুবার স্থানীয় সময় এক ঘণ্টা পরিবর্তিত হয় এবং অক্টোবরের শেষের দিকে এক ঘণ্টা পুনরাবৃত্তি হয়। স্থানীয় সময়ে লেখা লগগুলোতে সেই রাতে দুটি 02:30 এন্ট্রি থাকে, যা বিভিন্ন অঞ্চলের লগ মেলানোর কাজকে অনুমাননির্ভর করে তোলে। যদি আপনি তবুও সার্ভারে স্থানীয় সময় রাখতে চান, তবে তা স্পষ্টভাবে সেট করুন এবং যাচাই করুন:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

আউটপুটে গ্রীষ্মকালে Time zone: Europe/Berlin (CEST, +0200) এবং শীতকালে +0100 দেখানো উচিত।

ডিফল্ট C locale-এ জার্মান টেক্সট ভুলভাবে সর্ট হয়, কারণ C সর্টিং কাঁচা বাইট তুলনা করে। লোকাল জেনারেট করুন এবং পার্থক্য দেখুন:

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-এ এর প্রথম বাইট যেকোনো ASCII অক্ষরের চেয়ে বড়। দ্বিতীয় সর্টিং-এ এটি Apfel-এর পাশে থাকে, যেখানে একজন জার্মান পাঠক এটি আশা করেন। এটি দেখতে যতটা সাধারণ মনে হয় তার চেয়ে বেশি গুরুত্বপূর্ণ, কারণ PostgreSQL এবং MySQL ডাটাবেস তৈরির সময়ই কোলেশন (collation) ঠিক করে ফেলে এবং পরে তা পরিবর্তন করতে হলে ইনডেক্সগুলো পুনরায় তৈরি করতে হয়। ডেটা লোড করার আগেই সিদ্ধান্ত নিন।

একটি জার্মান প্যাকেজ মিরর apt রানকে দ্রুত করে। Ubuntu 24.04-এ সোর্সগুলো /etc/apt/sources.list.d/ubuntu.sources-এ deb822 ফরম্যাটে থাকে, তাই দ্বিতীয় কোনো ফাইল যোগ না করে URIs: লাইনটিকে http://de.archive.ubuntu.com/ubuntu/-এ পরিবর্তন করুন। একটি ফাইল যোগ করলে আপনি Target Packages ... is configured multiple times পাবেন, যা হলো deb822 ডুপ্লিকেট সোর্স এরর এবং এটি সমাধান না করা পর্যন্ত আপডেট বন্ধ থাকবে।

একটি AAAA রেকর্ড প্রকাশ করুন। কিছু জার্মান ISP গ্রাহকদের DS-Lite (dual-stack lite) সেটআপ প্রদান করে, যেখানে গ্রাহকের কোনো পাবলিক IPv4 অ্যাড্রেস থাকে না এবং তাদের IPv4 ট্রাফিক ক্যারিয়ারের ট্রান্সলেশন গেটওয়ে দিয়ে যায়। সেই গেটওয়ে ল্যাটেন্সি বাড়ায় এবং পিক আওয়ারের সময় জ্যাম তৈরি করে, যেখানে IPv6 ট্রাফিক সরাসরি বেরিয়ে যায়। রেকর্ড সেট করার পর উভয় পথই পরীক্ষা করুন:

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 বা কানেকশন এরর আসার অর্থ হলো রেকর্ড বা লিসেনার অনুপস্থিত, এবং আপনার DS-Lite ভিজিটররা ধীরগতির পথ ব্যবহার করছে।

ফ্রাঙ্কফুর্ট যখন সঠিক পছন্দ নয়

• আপনার ব্যবহারকারীরা যদি যুক্তরাষ্ট্রে থাকেন, তবে সেখান থেকেই তাদের সেবা দিন: ডালাসের একটি VPS দেশটির কেন্দ্রের কাছাকাছি অবস্থিত এবং নিউ ইয়র্কের VPS হোস্টিং পূর্ব উপকূলের জন্য এবং আটলান্টিক পাড়ি দেওয়া ট্রাফিকের জন্য সংক্ষিপ্ত পথ।
• আপনার ব্যবহারকারীরা যদি লাতিন আমেরিকায় থাকেন, তবে ফ্রাঙ্কফুর্ট থেকে সাও পাওলোর দূরত্ব নিউ ইয়র্কের চেয়ে বেশি। তাই সেই দর্শকদের জন্য ব্রাজিলের একটি VPS-ই সঠিক সমাধান।
• আপনার ডেটা যদি ইউরোপীয় ইউনিয়নের বাইরের কোনো নির্দিষ্ট দেশের ভেতরে রাখা বাধ্যতামূলক হয়। কানাডার সরকারি খাতের কাজ এর একটি সাধারণ উদাহরণ, এবং কানাডিয়ান VPS হোস্টিংয়ের ক্ষেত্রে যা গুরুত্বপূর্ণ তা সেখানে বসবাসের প্রয়োজনীয়তা নিয়ে আলোচনা করে।
• আপনি যদি গেম সার্ভার পরিচালনা করেন। খেলোয়াড়রা রাউন্ড-ট্রিপ টাইমের প্রতিটি মিলিসেকেন্ড অনুভব করতে পারে, তাই অন্য যেকোনো স্পেসিফিকেশনের চেয়ে তাদের কাছাকাছি অবস্থান থাকা বেশি গুরুত্বপূর্ণ: গেম সার্ভারের জন্য VPS নির্বাচন বিষয়টি এই প্রক্রিয়ার মাধ্যমে কাজ করে।

ইউরোপের বিভিন্ন দেশে ছড়িয়ে থাকা দর্শকদের জন্য ফ্রাঙ্কফুর্ট একটি নিরাপদ একক পছন্দ। আপনার ব্যবসার পরিধি বাড়লেও এটি নিরাপদ থাকে, কারণ আপনার প্রয়োজনীয় নেটওয়ার্কগুলো ইতিমধ্যেই সেখানে এক্সচেঞ্জে যুক্ত আছে। স্থানান্তরের আগে এবং পরে আপনার ব্যবহারকারীরা যেখান থেকে সংযোগ নিচ্ছেন সেখান থেকে পরিমাপ করুন এবং উভয় সেট ডেটা সংরক্ষণ করুন।

FAQ

পুরো ইউরোপের জন্য ফ্রাঙ্কফুর্টে একটি VPS কি যথেষ্ট?

অধিকাংশ প্রজেক্টের জন্য, হ্যাঁ। সরলরেখায় দূরত্বের হিসেবে স্টকহোমের জন্য সর্বনিম্ন 12.0 ms এবং মাদ্রিদের জন্য 14.2 ms ল্যাটেন্সি পাওয়া যায়। বাস্তব নেটওয়ার্ক পাথে এই মান সাধারণত সর্বনিম্ন মানের 1.5 থেকে 2 গুণ হয়, তাই পুরো ইউরোপীয় ইউনিয়নের প্রায় সব জায়গা থেকেই ফ্রাঙ্কফুর্টের একটি সার্ভারের ল্যাটেন্সি খুব কম থাকে। যখন কোনো নির্দিষ্ট দেশ থেকে ব্যবহারকারীদের কাছ থেকে সত্যিকারের অভিযোগ পাবেন অথবা গতির চেয়ে failover বেশি গুরুত্বপূর্ণ হবে, কেবল তখনই দ্বিতীয় একটি লোকেশন যোগ করার কথা ভাবুন।

ফ্রাঙ্কফুর্টে হোস্টিং করলে কি আমার প্রজেক্ট GDPR অনুগত হবে?

না। GDPR প্রযোজ্য হয় আপনি কার ব্যক্তিগত ডেটা প্রসেস করছেন এবং আপনার প্রতিষ্ঠান কোথায় অবস্থিত তার ওপর, সার্ভার কোথায় আছে তার ওপর নয়। ইউরোপীয় ইউনিয়নে হোস্টিং করলে ডেটা স্থানান্তরের আন্তর্জাতিক জটিলতা কমে, যা একটি বড় সুবিধা। তবে আপনাকে এখনও আইনগত ভিত্তি, ডেটা সাবজেক্টের অধিকার নিশ্চিত করা, ডেটা সংরক্ষণের সময়সীমা, নিরাপত্তা ব্যবস্থা, 72 ঘণ্টার মধ্যে লঙ্ঘন রিপোর্ট করা এবং আপনার প্রোভাইডারের সাথে একটি প্রসেসর এগ্রিমেন্ট (জার্মানিতে একে AVV বলা হয়) বজায় রাখতে হবে। এটি সাধারণ তথ্য, কোনো আইনি পরামর্শ নয়।

ফ্রাঙ্কফুর্ট এবং বার্লিনের মধ্যে কতটুকু ল্যাটেন্সি আশা করা উচিত?

শহর দুটির দূরত্ব 424 কিমি, যা রাউন্ড-ট্রিপ সময়ের জন্য 4.2 ms-এর একটি হার্ড ফ্লোর বা সর্বনিম্ন সীমা নির্ধারণ করে। একটি ভালো পিয়ারিং পাথে সাধারণত এই মানের 1.5 থেকে 2 গুণ ল্যাটেন্সি পাওয়া যায়। বার্লিনের একটি কানেকশন থেকে ping -c 20 your-server.example.com চালিয়ে এটি নিশ্চিত করুন এবং rtt min/avg/max/mdev লাইনে avg মানটি দেখুন। যদি ফলাফল এই সীমার চেয়ে অনেক বেশি হয়, তবে সাধারণত ট্র্যাফিক জার্মানির বাইরে গিয়ে আবার ফিরে এসেছে, যা mtr -rwzc 50-এর হপ নামগুলোতে দেখা যাবে।

আমার ফ্রাঙ্কফুর্ট সার্ভারের টাইমজোন কি Europe/Berlin-এ সেট করা উচিত?

সাধারণত না। সিস্টেমকে UTC-তে রাখুন যাতে লগগুলো তুলনামূলক থাকে এবং টাইমস্ট্যাম্প নিয়ে কোনো অস্পষ্টতা না থাকে। জার্মানি বসন্তে CEST এবং শরৎকালে CET-তে পরিবর্তিত হয়; শরৎকালের সেই রাতে একই স্থানীয় সময় দুইবার আসে, ফলে দুটি ভিন্ন ঘটনা একই লোকাল টাইমস্ট্যাম্প বহন করতে পারে। আপনার অ্যাপ্লিকেশনে লোকাল টাইম ফরম্যাট করুন, যেখানে এটি সঠিকভাবে করার জন্য প্রয়োজনীয় কনটেক্সট থাকে। যদি আপনি পুরো সার্ভারকে লোকাল টাইমে রাখতে চান, তবে sudo timedatectl set-timezone Europe/Berlin চালান এবং timedatectl দিয়ে যাচাই করুন।

শুধুমাত্র IPv4 সার্ভার কি জার্মান ব্যবহারকারীদের জন্য সমস্যা হবে?

এটি কাজ করবে, তবে কিছু ব্যবহারকারীর জন্য ধীরগতির হতে পারে। জার্মানির বেশ কয়েকটি ISP গ্রাহকদের DS-Lite সেটআপ দেয় যেখানে কোনো পাবলিক IPv4 অ্যাড্রেস থাকে না। ফলে সেই গ্রাহকরা ক্যারিয়ারের ট্রান্সলেশন গেটওয়ের মাধ্যমে IPv4-only সার্ভারে পৌঁছায়, যা ল্যাটেন্সি বাড়ায় এবং ব্যস্ত সময়ে কনজেশন তৈরি করে। একটি AAAA রেকর্ড পাবলিশ করা এবং IPv6-এ লিসেন করলে তারা সরাসরি কানেকশন পাবে। dig AAAA your-server.example.com +short এবং একটি curl -6 রিকোয়েস্ট দিয়ে এটি পরীক্ষা করুন এবং উভয় অ্যাড্রেস ফ্যামিলি থেকেই HTTP 200 রেসপন্স আশা করুন।