এমনকি কোনও ব্যান্ডউইথ বিতরণের জন্য একাধিক স্ট্যাটিক ফাইল সার্ভার জুড়ে ভারসাম্য লোড করার সর্বোত্তম উপায়?


12

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

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

আমি আমার বিকল্পগুলিতে অনেক চিন্তাভাবনা করেছি, তাই আমি প্রত্যেককে আপনাদের কাছে ব্যাখ্যা করব। আশা করি আপনি কিছুটা অন্তর্দৃষ্টি জোগাতে পারতেন যার মধ্যে একটি আমার পক্ষে সেরা বিকল্প, বা সম্ভবত সেখানে অন্য একটি বিকল্প আছে যা আমি এখনও ভাবিনি।

প্রয়োজনীয়তা:

  • এমনকি ব্যান্ডউইথ বিতরণও জরুরি। আমার কাছে বেশ শক্তিশালী সার্ভার রয়েছে, সুতরাং স্কেলিং করা কোনও বিকল্প নয়। আরও ব্যান্ডউইথ অর্জন করতে আমার স্কেল করা দরকার।

  • সংক্ষিপ্ত ইউআরএল। আমি সত্যিই আমার চিত্রগুলি পরিবেশন করতে img.example.com এর মতো একটি সাবডোমেন সেটআপ করতে চাই না। উদাহরণ.com/image.jpg এখন এটি কেমন এবং আমি কীভাবে এটি থাকতে চাই। তবে যদি অন্য কোনও উপায় না থাকে তবে আমি বুঝতে পারি।

  • অনুরোধটি পরিচালনা করে ক্লোস্টেস্ট সার্ভারটি সত্যিই দুর্দান্ত হবে তবে এটি অবশ্যই প্রয়োজন। কিছু মনে রাখবেন।

লোডবালেন্সে HAProxy:

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

ডিএনএস রাউন্ড রবিন:

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

সরাসরি সার্ভার রিটার্ন:

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

আদর্শভাবে, যদি HAProxy ডাইরেক্ট সার্ভার রিটার্ন সমর্থন করে, তবে আমার সমস্যাটি সমাধান হয়ে যাবে। আমি সিডিএনও ব্যবহার করতে চাই না, কারণ তারা সত্যই ব্যয়বহুল, এবং এটি সর্বোপরি কেবল একটি পার্শ্ব প্রকল্প।

আপনি আমার সমস্যা বুঝতে পারছেন? যদি আমি সঠিক কিছু ব্যাখ্যা না করি বা আপনার আরও তথ্যের প্রয়োজন হয় তবে আমাকে জানান।


1
এটি ইমগুর এবং সম্প্রতি ৪ কোটি ডলার সংগ্রহ করেছে। : ও
এল 1 ম 1 ম

উত্তর:


3

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

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


আপনাকে অনেক ধন্যবাদ. আপনার জরিপের ফলাফলগুলি খুব সহায়ক ছিল। আমি মনে করি এটিই আমি শেষ পর্যন্ত সমাধানে আসব। তবে, "যে কোনও ভাল গবেষকের মতো আমার কাছে পর্যাপ্ত ডেটা না পাওয়া পর্যন্ত আমি অভিনয় করি না।" :)
অ্যালান

অন্তর্দৃষ্টি জন্য আপনাকে ধন্যবাদ। দুর্ভাগ্যক্রমে আপনার অনুসন্ধানের সাথে একটি ব্যঙ্গাত্মকভাবে লিঙ্কটি মনে হচ্ছে, আপনি কি এটি ঠিক করতে পারেন?
TCB13

3

কিছু উত্তর:

  • হ্যাঁ, সমস্ত ট্র্যাফিক এইচপিপ্রক্সির মধ্য দিয়ে চলে যায়, কারণ এটি একটি HTTP স্তর প্রক্সি হিসাবে কাজ করে। এমনকি যদি পৃথক সার্ভারে HAProxy ইনস্টল করা থাকে যা একাধিক ব্যাক এন্ড সার্ভারগুলিকে ভারসাম্য বজায় রাখে তা সমান হবে। সুতরাং যদি আপনার হোস্টিং সরবরাহকারী কেবল 100MBit নেটওয়ার্ক পোর্ট সরবরাহ করে এবং আপনি ইতিমধ্যে 100MBit চাপ দিচ্ছেন তবে আপনার সমস্যা আছে।
  • ডোমেন সম্পর্কে, সর্বোত্তম জিনিসটি হ'ল আপনার ওয়েব অ্যাপের চেয়ে আলাদা ডোমেনের চিত্রগুলি সরবরাহ করা - কোনও সাবডোমেন নয়, আলাদা one যাতে চিত্রের অনুরোধের সাথে কুকিজ প্রেরণ করা হয় না। দেখুন স্টিভ Souders মূল কাজের , বা স্ট্যাক ওভারফ্লো উপর বাস্তবায়ন এখানে । যদি সংক্ষিপ্ত ইউআরএলগুলি আপনার কাছে খুব গুরুত্বপূর্ণ হয়, তবে ওয়েবপ্যাপটি মূল ইউআরএল থেকে সরিয়ে নেওয়া, অর্থাৎ ফাইল পরিচালনার অ্যাপ্লিকেশনটি login.sitename.com এ সরিয়ে নেওয়া সবচেয়ে ভাল কাজ হতে পারে?

আপনার কি চিত্রের অনুরোধগুলিতে প্রমাণীকরণের প্রয়োজন? যদি তা না হয় তবে অ্যামাজন এস 3 এর মতো কীভাবে ব্যবহার করবেন? এটি ব্যাপকভাবে স্কেলযোগ্য এবং ডেটা স্থানান্তর ব্যয় মোটামুটি সস্তা। এই ক্ষেত্রে আমি অ্যামাজন এস 3 বালতি হোস্টনামের জন্য ডিএনএস সিএনএম হিসাবে i.sitename.com এর মতো কিছু ব্যবহার করব, অ্যামাজন ডক্স দেখুন । এএআইএআইএকি সিএইএম হিসাবে আপনার রুট ডোমেন নাম (সিটেনাম.কম) থাকতে পারে না, সুতরাং এর জন্য আপনাকে অবশ্যই আই.সাইটেনাম.কমের মতো একটি সাবডোমেন ব্যবহার করতে হবে।

আপনি একাধিক সার্ভার জুড়ে আপনার চিত্রগুলিও হ্যাশ করতে পারেন। অর্থাৎ আপনি login.sitename.com এবং a.sitename.com এর মতো একটি ডিএনএস কাঠামো তৈরি করেন; b.sitename.com; c.sitename.com এবং সিটেরা। "ক।" এবং "খ।" ইত্যাদি সার্ভারগুলিতে চিত্র সহ একটি ফাইল সিস্টেম এবং একটি লাইটওয়েট এইচটিটিপি সার্ভার রয়েছে (আপনি ইতিমধ্যে লাইটটিপিডি ব্যবহার করছেন, তাই এটি ব্যবহার চালিয়ে যান a ভবিষ্যতের প্রকল্পের জন্য, আমি এনজিঙ্ক্সকে আরও ভাল প্রতিস্থাপন হিসাবে দেখার প্রস্তাব দেব) ব্যবহারকারী যখন আপলোড করে একটি চিত্র, আপনি একটি তৈরি একটি অনন্য শনাক্তকারী এর হ্যাশ, সম্ভবত তার ব্যবহারকারীর নাম, সম্ভবত ফাইলের নাম, বা একাধিক শনাক্তকারী সংমিশ্রণ । এই হ্যাশ থেকে, আপনি কোন সার্ভারটি চিত্রটি সঞ্চয় করবেন তা নির্ধারণ করুন।

সম্পাদনা আমার দেখা উচিত ছিল যে হ্যাশিং ইতিমধ্যে আলোচনা করা হয়েছিল। মূলত আমি এখানে যা প্রস্তাব করছি তা হল কেবল হোস্টনেমে হ্যাশিং ব্যবহার করা, একাধিক হোস্টে সমানভাবে নেটওয়ার্ক ট্র্যাফিক ছড়িয়ে দেওয়া।

আপনার এটি কতটা সস্তা হওয়া দরকার তা আমি জানি না - তবে আপনি যখন 100MBit নেটওয়ার্ক ট্র্যাফিকের দিকে চাপ দিচ্ছেন, তখন "সস্তা এবং ভাল" দ্রুত একটি বিভ্রম হিসাবে দেখা দেয়। হতে পারে আপনার প্রথমে ভাল ব্যবসায়ের মডেল পাওয়া উচিত, এমন কিছু যা পুনরাবৃত্তি উপার্জন সরবরাহ করে এবং তারপরে উপযুক্ত প্রযুক্তিটি প্রয়োগ করে?


1

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

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


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

1

আপনার হোস্টিং সরবরাহকারী লোড ব্যালেন্সিং পরিষেবাগুলি সরবরাহ করে? আমি মনে করি এটিই সেরা সমাধান।

এটি করার আরেকটি উপায়, তবে এটি পরীক্ষা করা দরকার, অনুরোধগুলি পুনর্লিখন করা (হালকা বা অ্যাপাচে) in উদাহরণস্বরূপ: example.com/file.html অ্যাপাচে থাকে এবং উদাহরণ.com/image.jpg i.example.com/image.jpg এ পুনঃনির্দেশ করে। সমস্ত অনুরোধগুলি অ্যাপাচি এর মাধ্যমে পরিচালিত হবে তবে রেপনসগুলি (আপস্ট্রিম ব্যান্ডউইথ) লাইটটিপিডি সার্ভারে যাচ্ছে। ডোমেনটি ব্যবহারকারীর কাছে স্বচ্ছ। তবুও আপনাকে পরীক্ষা করতে হবে যদি আপাচি সমস্ত অনুরোধগুলি পরিচালনা করতে পারে বা লাইটটিপিডিকে এই কাজটি করতে দেয়।

আপনি ঠিক বলেছেন যে সমস্ত ডেটা HAProxy এর মধ্য দিয়ে গেছে যাতে আপনি (যতদূর আমি জানি) এটির সাথে সরাসরি সার্ভারটি ফিরতে না পারে।

হালনাগাদ

তাকিয়ে HAProxy ডকুমেন্টেশন আমি "redir" প্যারামিটারটি পাওয়া যায় নি। আমি জানি না এটি অ্যাপাচি পুনর্লিখনের মতো কাজ করতে পারে তবে এটি কার্যকর হতে পারে। নথি বলছে:

প্রধান ব্যবহার ক্লায়েন্টদের সাথে সরাসরি সংযোগ স্থাপনের মাধ্যমে স্থিতিশীল সার্ভারগুলির জন্য ব্যান্ডউইথথ বাড়ানোর অন্তর্ভুক্ত।

হতে পারে এটি আপনার ক্ষেত্রে কাজ করে।


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

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

1

আমি ধরে নিচ্ছি যে কোনও আকারের বড় আকারের চিত্রের সাহায্যে আপনি চিত্রগুলির মূল ফাইলের উপর ভিত্তি করে স্টোর করছেন না কারণ আপনি খুব দ্রুত নাম দ্বন্দ্বের মধ্যে চলে যাবেন।

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

/image root/AA/AA/images  
/image root/AA/AB/images

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

খারাপ দিকটি হ্যাশগুলি নিখুঁত নয় এবং সংঘর্ষ হতে পারে। আমি কীভাবে এটি মোকাবেলা করা হয় তা নিশ্চিত নই। সুতরাং এটি আপনার পক্ষে কিছুটা গবেষণা নিতে পারে। আমি কল্পনা করেছি যে প্রক্সিটিতে একটি পুনর্লিখনের নিয়মটি A3A8BBC83261.jpg বলে একটি হ্যাশ নিতে সক্ষম হবে এবং এটি http://img3.domain.com/A3/A8/BBC83261.jpg- এ পুনরায় লিখতে সক্ষম হবে । যদিও আপনি এটি একটি সংক্ষিপ্ত url হিসাবে বিবেচনা করবেন না।


হ্যাঁ, ঠিক সেভাবেই আমি ছবিগুলি সঞ্চয় করছি। তবে সমস্যাটি স্টোরেজ নিয়ে নয়, এটি ব্যান্ডউইথ বিতরণ নিয়ে।
অ্যালান

তবে আপনি যদি একটি সার্ভারে 33 এবং 34 এর মাধ্যমে অন্য সার্ভারে 34 এর মাধ্যমে এএ সঞ্চয় করেন তবে আপনি কেবল স্টোরেজ সমস্যাটিকেই ব্যালেন্স করতে পারবেন না তবে ব্যান্ডউইথ বিতরণও।
3dinfluence

0

আপনার পোস্টে আপনি উল্লেখ করেছেন যে আপনি অনুভব করেছেন যে ডিএনএস রাউন্ড রবিনটি আপনার সেরা বিকল্প হতে পারে তবে আপনি একক সার্ভার ব্যর্থ হওয়ার বিষয়ে উদ্বিগ্ন ছিলেন ...

যদি কেসটি হয় তবে জেএইচ সফ্টওয়্যার থেকে সিম্পল ফেলোওভারটি একবার দেখুন। আমি এটি অতীতে ব্যবহার করেছি এবং এটি খুব ভালভাবে কাজ করে।

http://www.simplefailover.com

মূলত এটি আপনার সার্ভারগুলিকে পর্যবেক্ষণ করে এবং যখন এটি একটি ডাউন ডাউন দেখতে পায় এটি দ্রুত মৃত সার্ভারকে ঘূর্ণন থেকে বের করার জন্য ডিএনএসকে আবার লিখিত করে।

তাদের ওয়েবসাইট থেকে একটি স্নিপেট এখানে দেওয়া হয়েছে:

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

এটি ওয়েব-সার্ভার (HTTP), মেল-সার্ভার (এসএমটিপি, আইএমএপি, পিওপি 3), এফটিপি-সার্ভার এবং ব্যবহারিকভাবে অন্য কোনও টিসিপি / আইপি ভিত্তিক সার্ভারের সাথে কাজ করে।

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

অগত্যা নিখুঁত নয় ... তবে অবশ্যই দ্রুত এবং সহজ।

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

আমাদের ক্ষেত্রে, আমরা এটি কেবলমাত্র একটি এক্সপি মেশিনে ফেলেছি, মেশিনটিকে রাতে একবার রিবুট করতে বলেছিলাম, এবং এটি বছরের পর বছর ধরে চলে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.