সেশন সংখ্যা সীমাবদ্ধ কিভাবে?


8

একটি ওয়েব অ্যাপ্লিকেশনটিতে ওয়েব সেশনগুলি সন্ধান এবং সীমাবদ্ধ করার জন্য আমার একটি উপায় প্রয়োজন। একটি "সেশন" হ'ল একটি ওয়েব ব্যবহারকারী হিসাবে উল্লিখিত ওয়েব অ্যাপ্লিকেশনগুলির পৃষ্ঠাগুলি ব্রাউজ করে সংজ্ঞায়িত করা হয়। আমি মনে করি এটি অনুবাদ করা যেতে পারে:

  • একটি সেশন tuple হিসাবে সংজ্ঞায়িত করা হয় <clientIP,vHost>অন্যথায় যেমন <clientIP,serverIP,serverPort>বা <cookie,vHost>, স্তর এবং ডেটা উপলব্ধ উপর নির্ভর করে
  • ব্যবহারকারী একটি সংজ্ঞায়িত লগইন ইউআরআইতে প্রমাণীকরণ ডেটা প্রেরণের পরে একটি অধিবেশন শুরু হয়
  • ব্যবহারকারী নির্ধারিত লগআউট ইউআরআই হিট করার পরে একটি অধিবেশন শেষ হয়
  • ক্লায়েন্টটি শেষ অবজেক্টটির জন্য অনুরোধ করার পরে নির্দিষ্ট সময়সীমা শেষ হয়ে গেলে একটি সেশন শেষ হয়

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

আমি যা দিয়ে কাজ করতে পারি:

  • রেডওয়্যার অ্যাপডিরেক্টর যেখানে ওয়েব অ্যাপ্লিকেশনটির নিজস্ব খামার সংজ্ঞায়িত হয়েছে এবং বিপরীত প্রক্সি মোডে চলছে
  • অ্যাপাচি ২.২
  • এসইএলএস 11 এসপি 2

আমি কোনও অতিরিক্ত প্রক্সি সার্ভার জড়িত না করা পছন্দ করব, যদিও অন্য কোনও বিকল্প না থেকে থাকলে এটি বিবেচনা করবে।

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

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

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


আপনি কি ওয়েব অ্যাপে সাধারণ বিবরণ সরবরাহ করতে পারেন? এটি কি প্রতিটি ভিস্টে একরকম? অথবা আপনি বিশদটি সরবরাহ করেন নি, কারণ আপনি সম্ভবত এমন কোনও সমাধান চান যা ওয়েব অ্যাপ্লিকেশন থেকে পৃথক? এটি কি মালিকানাধীন ওয়েব অ্যাপ?
lsmooth

সংযোগ বন্ধ হওয়ার পরে, নিষ্ক্রিয়তার কারণে, কেউ সেশন কুকি ব্যবহার করে কোনও সেশন পুনরায় চালু করতে পারেন (যদি অ্যাপ্লিকেশনটির সময়সীমাটি শেষ না হয়ে থাকে)?
মনজিকি

@ জিজিক্স এটি একটি সীমান্ত মামলা যা এটি বাস্তবায়নের জটিলতায় যোগ করলে এটি নিয়ে বিরক্ত করার পক্ষে যথেষ্ট বিরল বলে বিবেচিত হয়। তা ছাড়া, আমি মনে করি এটি সেশন সীমা ছাড়াই পরীক্ষা না করে সেশনটিকে পুনরায় ইনস্টল করা হিসাবে সেরা হিসাবে নির্দিষ্ট করা যেতে পারে ।
দ্য ওয়াববিট

আমি সাধারণত httpd- অ্যাক্সেস-লগতে "সাধারণ" url গণনা করে এটি করি। আমরা এখানে মোটামুটি সংখ্যার কথা বলছি? সম্ভবত একটি থ্রেড-সীমা এখানে httpd- সাইডে সহায়তা করতে পারে?
নিলস

আমি জানি HAProxy সংযোগের সংখ্যা সীমাবদ্ধ করতে পারে। তবে আপনি কিছুটা আলাদা জিজ্ঞাসা করছেন ...
ম্যাট

উত্তর:


5

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

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

পর্যবেক্ষণের উদ্দেশ্যে সেশনের বর্তমান সংখ্যা ট্র্যাক করার জন্য আমারও একটি উপায় প্রয়োজন

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


আমার উপরের প্রশ্নগুলি ভুলে যাও, আমি ঠিক এটাই পেয়ে যাচ্ছিলাম।
lsmooth

আপনি কি নিশ্চিত যে র‌্যাডওয়্যার অ্যাপডিরেক্টর অন্তত প্রসারিত চিকিত্সায় এই সমস্যাটি সমাধান করতে পারে না? - নোড ওভারলোডিং যাতে অন্য উপায়ে অর্জন করা যায় তা রোধ করার জন্য সেশন নিয়ন্ত্রণের অনুরোধ জানানো হয়।
ভেনিয়ামিন

তার অনেক কিন্তু - কোনো আমি নিশ্চিত নই - আমি আগেই বলেছি উপরে আপনি স্ট্যাক অন্যত্র সেশন ম্যানেজমেন্ট অর্থহীন করতে অনেক বেশি ভুল জায়গায় এটা করতে কঠিন। যেখানে সমস্যা হচ্ছে সেখানে স্থির করা অনেক সহজ much
সিমকিবিয়ান

আপনি যদি সেশন ম্যানেজমেন্টের জন্য সঠিক জায়গাটি বিবেচনা করেন তবে অ্যাপ্লিকেশন বা অন্য কোথাও নোডের ভিত্তিতে সংহত একটি মডিউল যা অ্যাপডিরেক্টর স্তরে লোড ব্যালেন্সিংয়ের সাথে এটি কীভাবে একসাথে কাজ করবে তা পরিষ্কার নয়।
ভেনিয়ামিন

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

1

এটি আপনি যা চেয়েছিলেন ঠিক তা নয়, তবে ইতিমধ্যে F5 লোড ব্যালান্সারগুলির সাথে নিম্নলিখিতটি সম্পন্ন করেছি:

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

ওয়েবসাইটটি কখনও কখনও ভারী বোঝা (ঘোড়ার দৌড়) এর অধীনে থাকায় এটি সহায়তা করেছিল।


ধারণাটির জন্য ধন্যবাদ, আমরা যদি আমাদের অনুরূপ কিছু বাস্তবায়ন করতে পারি তবে আমাদের অ্যাপডাইরেক্টর ছেলেদের সাথে আমার পরীক্ষা করা দরকার।
দ্য ওয়াবিট

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

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

1

এই সমস্যাটি রেডওয়্যার অ্যাপডিরেক্টর ব্যবহার করে এবং (সম্পূর্ণতার জন্য) উভয়ই সমাধানযোগ্য, নীচের মন্তব্যে আপনার দুর্দান্ত সন্ধান অনুসারে অ্যাপাচি মোড_সিকিউরিটি ব্যবহার করে।

একটি অ্যাপডিরেক্টর সমাধানের জন্য আমি বিশ্বাস করি একই ব্যাকএন্ড সার্ভার (গুলি) এ দুটি ফার্ম ম্যাপিং সম্ভব। এই ফার্মগুলিতে তাদের জন্য বিভিন্ন মানদণ্ড এবং অপারেটিং শর্ত প্রয়োগ করা যেতে পারে। একটি খামার "ডিফল্ট" হবে এবং অন্যটি ইউআরআইয়ের উত্তর দেবে: আপনি "অধিবেশন" হিসাবে সংজ্ঞায়িত করেছেন। পরেরটি লোড ব্যালেন্সারে গ্রহণ করে এমন পরিমাণ সেশনের সীমা পাবে।

আমি এখন থেকে আপনার "অধিবেশন" পদটি দুটি কারণে "লগ ইন" করার পরিবর্তে যাচ্ছি:

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

"লগ ইন" ফার্মটি যদি নির্বাচিত সংযোগের সীমাতে পৌঁছে যায় তবে একটি দুঃখিত পৃষ্ঠা দেখাও সম্ভব।

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

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

মূলত ব্যবহারকারী গাইডের মাধ্যমে ব্যাখ্যা করা হিসাবে এখানে একটি সমাধানের খসড়াটি রয়েছে:

লোড ব্যালান্সারের ক্লায়েন্ট এন্ট্রি একটি ভিআইপি-র মাধ্যমে করা হয় যা "ডিফল্ট" সেশন এবং "লগ ইন সেশন" উভয়কে সংযোগ করতে ব্যবহৃত হয়। এটি ইউজার গাইডে p.99 অনুসারে একটি L4 নীতি দ্বারা অর্জন করা হয়েছে:

"When AppDirector receives the first packet of a session destined to a
Virtual IP address, it searches for a Layer 4 Policy that matches the
Layer 4 Protocol, Destination port, Source IP, etc. Then, based on this
information, AppDirector selects the farm allocated to this service and
the best server for the task from that farm, and forwards the packet to
that server.

L4 নীতিটি L7 নীতিগুলির সাথে যুক্ত হতে পারে যা একটি উপযুক্ত খামার নির্বাচন করতে ব্যবহৃত হয়। L7 নীতি প্রক্রিয়াটি ব্যবহারকারী গাইড পৃষ্ঠা 104 তে এভাবে বর্ণিত হয়েছে:

"The Layer 7 content aware decision making mechanism allows you to have
a single point of entry to the site, and provides differentiated service
for different user groups.

A Layer 7 decision is made using a mechanism called Delayed Binding.
When Delayed Binding is used, AppDirector first performs a TCP handshake
with the client to receive the HTTP request. AppDirector parses the HTTP
request’s data, usually HTTP headers, and performs the load balancing
decision. Only after that, does AppDirector select a farm and a server.
Lastly, AppDirector initiates a TCP handshake with the server and
forwards the traffic to it
[...]
When Layer 7 Policies are used, farm selection is based on matching the
request data with a list of Layer 7 Policies defining the Layer 7
parameters differentiating the service. The process of server selection
within the farm can also be content-based, using a third Layer 7
parameter."

এল 7 আচরণ সংজ্ঞায়িত করার জন্য উপলভ্য পদ্ধতিগুলি p.106-এ সংক্ষিপ্ত করা হয়েছে, যার মধ্যে আপনি "ডিফল্ট" ফার্মের পরিবর্তে আপনার "লগ ইন" ফার্মের রাউটিং চয়ন করার জন্য একটি উপযুক্ত পদ্ধতি বেছে নিতে পারেন:

"Methods are the basic building blocks for Layer 7 service selection.
They define content by which traffic is differentiated. You can use
the same Method to select one or more services. The following Method
Types are available:

- URL: Looks for a specified host name and/or path in the HTTP request.
- File Type: Looks for a specified File Type in the HTTP request.
- Header Field: Looks for a specified Header Field in the HTTP request.
- Cookie: Looks for a specified Cookie in the HTTP request.
- Regular Expression: Looks for a regular expression anywhere in the
HTTP request. AppDirector supports Posix 1002.3 regular expressions;
the string can be up to 80 characters.
- Text: Looks for a text string anywhere in the HTTP request."

বেসিক অ্যাপ্লিকেশন লিঙ্কটিতে যেমন দেখা যায় , উদাহরণস্বরূপ, কেউ কেউ বিভিন্ন খামারে রাউটিংয়ের জন্য ইউআরআই নিদর্শনগুলির মূল্যায়ন করে একটি এল 7 নীতি তৈরি করতে পারে। তৈরি ইউআরআই নিদর্শনগুলি '^ / লগইন? = সত্য' এবং '^ / লগইন' আপনার "লগ ইন" খামারে যেতে পারে। তৈরি করা প্যাটার্ন '^ / লগআউট' (এবং অন্যান্য সমস্ত ইউআরআই: গুলি) একইভাবে একটি "ডিফল্ট" ফার্মে যেতে পারে।

একটি ফার্ম ব্যবহারকারীর নির্দেশিকা p.121 দ্বারা এইভাবে সংজ্ঞায়িত করা হয়েছে: "একটি অ্যাপডাইরেক্টর ফার্ম একটি নেটওয়ার্ক সার্ভারের একটি গ্রুপ যা একই পরিষেবা সরবরাহ করে [...] একাধিক পরিষেবা সরবরাহকারী একটি সার্ভার একাধিক খামারে ব্যবহার করা যেতে পারে" "

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

একটি ফার্মে সীমা সীমাবদ্ধ করা প্রতিটি অ্যাপ্লিকেশন সার্ভার অবজেক্টের পাশাপাশি প্রতিটি ফার্ম সার্ভার অবজেক্ট (পাশাপাশি অন্যান্য উপায়ের মাধ্যমে) প্রতি শারীরিক সার্ভার অবজেক্ট ছাড়াও 'অ্যাপডাইরেক্টর ইউজার গাইড' অনুযায়ী করা যেতে পারে। এটি অন্য জায়গাগুলির মধ্যে p.137 তে বর্ণিত হয়েছে:

"The Connection Limit is the maximum number of users that can be directed
to a server for a service provided by the farm. The number of users allowed
depends on the Sessions mode selected because it determines the number of
active entries in the Client Table for sessions destined to the specific server.

When the Entry Per Session or Server Per Session modes are selected, the number
of active entries destined to the same server is higher than in the Regular
mode (see Regular, page 153).

When the Regular mode is selected, all requests from a single client IP destined
to the same server are reflected by a single entry in the Client Table (see
Client Table Views, page 164).

The default value for the Connection Limit parameter is 0. When it is configured
to 0, it is disabled for this server and there is no user number limit."

ক্লায়েন্ট টেবিল এবং তার 'নিয়মিত মোড' p.153 এ সংজ্ঞায়িত করা হয়েছে:

"The Layer 3 Client Table is always used when Entry Per Session is used.
AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency.

This table contains information about the server selected for each client
(Source IP address) in each farm, and it allows AppDirector to select a
server for a new session.
[...]
In the Regular mode, AppDirector maintains Layer 3 persistency. In this mode,
each entry is identified by the following parameters:
• Layer 4 Policy VIP Address
• Client IP Address
• Destination TCP/UDP Port Used from the Client to the Server"

বেসিক অ্যাপ্লিকেশন পৃষ্ঠায় একটি সার্ভার সংজ্ঞা উইন্ডোর স্ক্রিনশটে, ব্যান্ডউইথ সীমা বাক্সের ঠিক পাশেই সার্ভার সংযোগ সীমাবদ্ধতা বাক্সটি দেখা যায়।

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

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

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

সংযোগের সীমাটি নির্ধারণ করতে কিছুটা কৌতূহল রয়েছে। শারীরিক সার্ভার থেকে, সংযোগ সীমা p.140:

"Connection Limit

Maximum number of Client Table entries that can run simultaneously on 
the physical server. This depends on the farm’s Sessions mode (see 
Sessions Modes, page 150). When the limit is reached, new requests are 
no longer directed to this server. All open sessions are continued.

When the Connection Limit parameter is configured to 0 (default), this 
mechanism is disabled for this physical server and there is no user 
number limit.

Note: When configuring the physical server, ensure that the Connection 
Limit in the farm servers with the same Server Name is lower than or 
equal to the Connection Limit in the physical server. Total number of 
active sessions that run simultaneously on the farm servers must not 
be higher than the Connection Limit value defined on the physical server."

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


আপনার প্রশ্নেও আপনার এই প্রয়োজনীয়তা রয়েছে:

After the specified session limit has been reached, the next user should be
directed to a custom error page.

এটি ব্যবহারকারী নির্দেশিকা, পৃষ্ঠায় একটি 'এইচটিটিপি পরিষেবা পৃষ্ঠা নয়' হিসাবে অভিহিত হয়েছে:

When all servers belonging to a farm cannot be used for a specific
session, AppDirector can reply to a Web request (destined to port 80)
with a simple Web page, indicating that the service is currently not
available. Servers that cannot be used for a session include servers
in Not In Service or in No New Sessions mode. No HTTP Service Page is
configured for each farm. Each Web page is limited to 1K of HTML code.

পর্যবেক্ষণ অংশের জন্য আমি পুরো গবেষণা হিসাবে কাজ করি নি তবে এখানে আমি যা মনে করি তা এখানে:

track the current number of sessions for monitoring purposes

অ্যাপডাইরেক্টরতে এমআইবি রয়েছে বলে মনে হচ্ছে। সম্ভবত সঠিক ওআইডিটি যেমন হয় ঠিক তেমন কোনও ব্যথা, তবে আপনি সম্ভবত এটি আপনার পছন্দসই সরঞ্জামটিতে স্ন্যাপ করতে পারেন।

whitelist the monitoring server (which is issuing queries to the webapp
periodically) and exempt it from the limit.

এটির জন্য কিছু সৃজনশীল চিন্তাভাবনা প্রয়োজন। অ্যাপডিরেক্টর ধরে নিলে বাক্সের বাইরে এই কোনও টেম্পলেট অন্তর্ভুক্ত নেই, কীভাবে:

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

1
এখনও অবধি আমি খুঁজে পেয়েছি যে মোড_সিকিউরিটি ২ মডিউলটি এমনভাবে সেশন পরিচালনা করতে সক্ষম যা আমি যা নির্দিষ্ট করেছিলাম তার সাথে অনেকটা সাদৃশ্যপূর্ণ - Safe.jwall.org/blog/2009/01/08/1231374852674.html । আমি আপনার 2 টি খামার সম্পর্কে আপনার ধারণা সম্পর্কে আরও কিছু গবেষণা করতে যাচ্ছি, যদি এরূপ বাস্তবায়ন সম্ভব হয় তবে এটি অবশ্যই জিনিসগুলিকে সরল করে তুলবে।
দ্য ওয়াবিট

রেডওয়্যার প্রযুক্তিগত সহায়তা থেকে প্রতিক্রিয়া: "এডি তে আমরা কেবলমাত্র ফার্ম প্রতি ব্যান্ডউইথ সীমাবদ্ধ করতে পারি। [...] [এ] খামারের ভিত্তিতে মোট সেশনের সংখ্যা সীমিত করার পদ্ধতি বর্তমানে পাওয়া যায় না।" সুতরাং এটি mod_ সুরক্ষিত হয়।
দ্য ওয়াবিট

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

সম্ভবত প্রশ্নটি ব্যাখ্যা করার ক্ষেত্রে সমর্থনটি কিছুটা সংকীর্ণ হলেও এটি অ্যাপডায়রেক্টরে সার্ভার স্তরের একটি সেশন সীমা উপস্থিত থাকতে পারে (যার পক্ষে অবশ্যই কিছুটা যুক্তি রয়েছে)। আমি বেশ কয়েকটি লিঙ্ক গুগল করেছিলাম
২২২

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

0

যদি অ্যাপডায়রেক্টর আপনাকে সহায়তা করতে না পারে তবে এখানে আরও একটি পদ্ধতি যা কোডিংয়ের প্রয়োজন হবে। আমি সমস্যাটি এইভাবে সমাধান করেছি:

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

সেশনগুলির সংখ্যা অঙ্কিত করা iptables শৃঙ্খলার দৈর্ঘ্যের গ্রাফিংয়ের মতো সহজ হয়ে যায়। নিরীক্ষণ সার্ভারটি সর্বদা শ্বেত তালিকাভুক্ত হতে পারে।

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