Nginx HAProxy এর সামনে বা বিপরীতে হওয়া উচিত?


11

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

1) কিছু পৃষ্ঠার জন্য যেমন HTTPS সহায়তা প্রয়োজন (যেমন লগইন পৃষ্ঠা) অন্যরা কেবল HTTP পৃষ্ঠা page

2) একাধিক ওয়েব সার্ভারের প্রয়োজন যাতে কিছু লোড ব্যালেন্সিং প্রয়োজন।

3) পারফরম্যান্স বাড়ানোর জন্য এইচটিটিপি ক্যাচিং এবং সংক্ষেপণের প্রয়োজন।

4) কিছু অনুরোধ (যেমন চিত্র আপলোডিং) ডেডিকেটেড ব্যাকএন্ড সার্ভারগুলিতে পাঠানো উচিত। সুতরাং, ইউআরএল-ভিত্তিক ভারসাম্য প্রয়োজন।

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

সুতরাং, আমি কি এনগিনেক্সকে (বিপরীত প্রক্সি হিসাবে) HAProxy (লোড ব্যালেন্সার হিসাবে) এর সামনে রেখে দেব বা বিপরীতে?

ধন্যবাদ

উত্তর:


7

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

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

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


ধন্যবাদ। যেহেতু "কিছু অনুরোধগুলি (যেমন চিত্র আপলোডিং) ডেডিকেটেড ব্যাকএন্ড সার্ভারগুলিতে পাঠানো উচিত So সুতরাং, ইউআরএল-ভিত্তিক ব্যালেন্সিং প্রয়োজন।" (আমি যেমন প্রশ্ন আপডেট করেছি)। এলভিএস আমার প্রয়োজনীয়তাগুলি পরিবেশন করতে পারে না।
মরগান চেং

বিটিডাব্লু, এইচএপি প্রক্সির আইপি ঠিকানা লুকানো কেবল এইচটিটিপিএসের জন্য, বা এইচটিটিপি-র জন্যও?
মরগান চেং

@ মরগান, আইপি লুকানো কেবল এইচটিটিপিএসের জন্য।

এটি কেবলমাত্র টিসিপি-মোড ব্যাকেন্ডের জন্য, তাই HTTP নয় এমন যে কোনও কিছু এটি HTTP শিরোনাম (এক্স-ফরওয়ার্ড-ফর) হিসাবে প্রেরণের পরে আইপি ঠিকানাটি দেখতে পাবে না।

বেপারটা এমন না. Haproxy ক্লায়েন্টের আইপি ঠিকানা ব্যবহার করে সার্ভারের সাথে সংযোগ স্থাপন করতে পারে তবে এর জন্য কার্নেল সহযোগিতা প্রয়োজন (যেমন: TPROXY বৈশিষ্ট্য)। এটি যেখানেই সম্ভব এড়ানো উচিত।
উইলি তারেরre


1

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


2
বলা হয়ে থাকে যে এনগিনএক্স লোড ব্যালেন্সিং সহজ, কেবল রাউন্ড রবিন অ্যাপ্রোচ। এই কারণেই আমি HAProxy বিবেচনা করছি।
মরগান চেং

1
এটি সঠিকভাবে বলা হয়; আমি নিজেই বলেছি। এ কারণেই আমি লোড ব্যালেন্সার হিসাবে এনগিনেক্স ব্যবহার করার পরামর্শ দিচ্ছি না, এবং আমার এই (বা অন্য কোনও) উত্তরে আপনি লোড ব্যালান্সার হিসাবে nginx ব্যবহারের কোনও উল্লেখ খুঁজে পাবেন না।
দোলা

কেবলমাত্র যদি আপনি উত্স থেকে নিজস্ব সংকলন (বা ফ্রিবিএসডি-র পোর্ট) ব্যবহার করতে ভয় পান। একাধিক তৃতীয় পক্ষের মডিউল রয়েছে যা লোড ভারসাম্য উন্নত করে: wiki.nginx.org/3rdPartyModules
মার্টিন Fjordvald

2
হ্যাঁ, উন্নতি করুন। পর্যাপ্ত করুন, না। এ সম্পর্কে আমার মতামত hezmatt.org/~mpalmer/blog/2011/07/24/… ("সুন্দর নয়" অনুসন্ধান করুন) পাওয়া যাবে।
দোলা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.