200TB+ ইলাস্টিক সার্চ ক্লাস্টার

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

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

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

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

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

সিস্টেমের প্রয়োজনীয়তাগুলি নিম্নরূপ প্রণয়ন করা হয়েছিল:

• গ্রেলগ ফ্রন্টএন্ড হিসাবে ব্যবহার করা হবে। যেহেতু কোম্পানির ইতিমধ্যে এই পণ্যটি ব্যবহার করার অভিজ্ঞতা ছিল, প্রোগ্রামার এবং পরীক্ষকরা এটি জানত, এটি তাদের কাছে পরিচিত এবং সুবিধাজনক ছিল।
• ডেটা ভলিউম: প্রতি সেকেন্ডে গড়ে 50-80 হাজার বার্তা, কিন্তু যদি কিছু ভেঙে যায়, তবে ট্র্যাফিক কিছু দ্বারা সীমাবদ্ধ নয়, এটি প্রতি সেকেন্ডে 2-3 মিলিয়ন লাইন হতে পারে
• গ্রাহকদের সাথে অনুসন্ধানের প্রশ্নগুলি প্রক্রিয়াকরণের গতির প্রয়োজনীয়তা নিয়ে আলোচনা করার পরে, আমরা বুঝতে পেরেছি যে এই ধরনের একটি সিস্টেম ব্যবহার করার সাধারণ প্যাটার্ন হল: লোকেরা গত দুই দিন ধরে তাদের আবেদনের লগগুলি খুঁজছে এবং একটির বেশি অপেক্ষা করতে চায় না একটি প্রণীত প্রশ্নের ফলাফলের জন্য দ্বিতীয়।
• অ্যাডমিনিস্ট্রেটররা জোর দিয়েছিলেন যে সিস্টেমটি কীভাবে কাজ করে তা গভীরভাবে অনুসন্ধান করার প্রয়োজন ছাড়াই প্রয়োজনে সিস্টেমটি সহজেই স্কেলযোগ্য হতে পারে।
• যাতে শুধুমাত্র রক্ষণাবেক্ষণের কাজটি যা এই সিস্টেমগুলির জন্য পর্যায়ক্রমে প্রয়োজন তা হল কিছু হার্ডওয়্যার পরিবর্তন করা।
• এছাড়াও, ওডনোক্লাসনিকির একটি চমৎকার প্রযুক্তিগত ঐতিহ্য রয়েছে: আমরা যে পরিষেবা চালু করি তা অবশ্যই ডেটা সেন্টারের ব্যর্থতা থেকে বাঁচতে হবে (হঠাৎ, অপরিকল্পিত এবং যে কোনও সময়)।

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

পরিবেশ

আমরা চারটি ডেটা সেন্টারে কাজ করি, যখন ইলাস্টিকসার্চ ডেটা নোডগুলি শুধুমাত্র তিনটিতে অবস্থিত হতে পারে (অনেকটি অ-প্রযুক্তিগত কারণে)।

এই চারটি ডেটা সেন্টারে প্রায় 18 হাজার বিভিন্ন লগ সোর্স রয়েছে - হার্ডওয়্যার, কন্টেইনার, ভার্চুয়াল মেশিন।

গুরুত্বপূর্ণ বৈশিষ্ট্য: ক্লাস্টারটি পাত্রে শুরু হয় পোডম্যান ভৌত মেশিনে নয়, কিন্তু চালু নিজস্ব ক্লাউড পণ্য এক-মেঘ. কন্টেইনারগুলি 2Ghz v2.0 এর মতো 4 কোরের গ্যারান্টি দেওয়া হয়, যদি তারা নিষ্ক্রিয় থাকে তবে অবশিষ্ট কোরগুলি পুনর্ব্যবহার করার সম্ভাবনা রয়েছে৷

অন্য কথায়:

টপোলজি

আমি প্রাথমিকভাবে সমাধানের সাধারণ ফর্মটি নিম্নরূপ দেখেছি:

• 3-4 ভিআইপি গ্রেলগ ডোমেনের A-রেকর্ডের পিছনে রয়েছে, এটি সেই ঠিকানা যেখানে লগগুলি পাঠানো হয়৷
• প্রতিটি ভিআইপি একটি এলভিএস ব্যালেন্সার।
• এর পরে, লগগুলি গ্রেলগ ব্যাটারিতে যায়, কিছু ডেটা GELF ফর্ম্যাটে, কিছু syslog ফর্ম্যাটে থাকে৷
• তারপর এই সমস্ত ইলাস্টিকসার্চ সমন্বয়কারীর ব্যাটারিতে বড় ব্যাচে লেখা হয়।
• এবং তারা, ঘুরে, প্রাসঙ্গিক ডেটা নোডগুলিতে লিখতে এবং পড়ার অনুরোধ পাঠায়।

পরিভাষা

সম্ভবত সবাই পরিভাষাটি বিশদভাবে বোঝে না, তাই আমি এটির উপর একটু চিন্তা করতে চাই।

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

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

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

ডেটা নোড
ডেটা সঞ্চয় করে, বাইরে থেকে আগত অনুসন্ধান ক্যোয়ারীগুলি সঞ্চালন করে এবং এটিতে অবস্থিত শার্ডগুলিতে অপারেশন করে৷

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

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

দৃশ্যত এটি এই মত কিছু দেখায়:

এটি একটি নির্দিষ্ট উদাহরণ থেকে একটি স্ক্রিনশট। এখানে আমরা সার্চ কোয়েরির উপর ভিত্তি করে একটি হিস্টোগ্রাম তৈরি করি এবং প্রাসঙ্গিক সারি প্রদর্শন করি।

সূচকের

সিস্টেম আর্কিটেকচারে ফিরে, আমি কীভাবে সূচক মডেলটি তৈরি করেছি সে সম্পর্কে আরও বিশদে থাকতে চাই যাতে এটি সমস্ত সঠিকভাবে কাজ করে।

উপরের চিত্রে, এটি সর্বনিম্ন স্তর: ইলাস্টিকসার্চ ডেটা নোড।

একটি সূচক হল একটি বড় ভার্চুয়াল সত্তা যা ইলাস্টিকসার্চ শার্ডের সমন্বয়ে গঠিত। নিজের মধ্যে, প্রতিটি শার্ড লুসেন সূচক ছাড়া আর কিছুই নয়। এবং প্রতিটি লুসিন সূচক, ঘুরে, এক বা একাধিক অংশ নিয়ে গঠিত।

ডিজাইন করার সময়, আমরা ভেবেছিলাম যে প্রচুর পরিমাণে ডেটা পড়ার গতির প্রয়োজনীয়তা পূরণ করার জন্য, আমাদের এই ডেটাটিকে ডেটা নোডগুলিতে সমানভাবে "প্রসারিত" করতে হবে।

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

আমরা প্রথমে 30 দিন হিসাবে স্টোরেজ সময় নির্ধারণ করেছি।

শার্ডের বন্টন গ্রাফিকভাবে নিম্নরূপ উপস্থাপন করা যেতে পারে:

সম্পূর্ণ গাঢ় ধূসর আয়তক্ষেত্র একটি সূচক। এটিতে বাম লাল বর্গক্ষেত্রটি প্রাথমিক শার্ড, সূচকে প্রথমটি। এবং নীল বর্গক্ষেত্র হল একটি প্রতিরূপ শার্ড। তারা বিভিন্ন ডেটা সেন্টারে অবস্থিত।

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

সূচকের ঘূর্ণন, যেমন একটি নতুন সূচী তৈরি করা এবং সবচেয়ে পুরানোটি মুছে ফেলার জন্য, আমরা এটিকে 48 ঘন্টার সমান করেছি (সূচী ব্যবহারের ধরণ অনুসারে: শেষ 48 ঘন্টা প্রায়শই অনুসন্ধান করা হয়)।

এই সূচক ঘূর্ণন ব্যবধান নিম্নলিখিত কারণে হয়:

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

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

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

ফলস্বরূপ, আমরা দেখতে পেয়েছি যে গড়ে একটি শার্ডের ওজন প্রায় 20 গিগাবাইট এবং প্রতি সূচকে 1 টি শার্ড রয়েছে। তদনুসারে, যদি আমরা প্রতি 360 ঘন্টায় একবার সেগুলি ঘোরান, তবে আমাদের কাছে সেগুলির মধ্যে 48টি রয়েছে। প্রতিটি সূচকে 15 দিনের জন্য ডেটা থাকে।

ডেটা রাইটিং এবং রিডিং সার্কিট

আসুন এই সিস্টেমে ডেটা কীভাবে রেকর্ড করা হয় তা বের করা যাক।

ধরা যাক গ্রেলগ থেকে সমন্বয়কারীর কাছে কিছু অনুরোধ আসে। উদাহরণস্বরূপ, আমরা 2-3 হাজার সারি সূচক করতে চাই।

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

মাস্টার উত্তর দেন: "এই তথ্যটি শার্ড নম্বর 71-এ লিখুন," এর পরে এটি সরাসরি প্রাসঙ্গিক ডেটা নোডে পাঠানো হয়, যেখানে প্রাথমিক-শার্ড নম্বর 71 অবস্থিত।

এর পরে লেনদেন লগটি একটি প্রতিলিপি-শার্ডে প্রতিলিপি করা হয়, যা অন্য ডেটা সেন্টারে অবস্থিত।

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

180টি নোড অসমভাবে সাড়া দেয়, এবং যখন তারা সাড়া দিচ্ছে, তখন সমন্বয়কারী তথ্য জমা করছে যা ইতিমধ্যেই দ্রুত ডেটা নোড দ্বারা "থুতু ফেলা হয়েছে"। এর পরে, যখন হয় সমস্ত তথ্য পৌঁছে যায়, বা অনুরোধের সময়সীমা পৌঁছে যায়, এটি সরাসরি ক্লায়েন্টকে সবকিছু দেয়।

এই পুরো সিস্টেমটি গত 48 ঘন্টার জন্য 300-400ms এর মধ্যে সার্চ ক্যোয়ারীগুলিকে প্রক্রিয়া করে, একটি নেতৃস্থানীয় ওয়াইল্ডকার্ড সহ সেই প্রশ্নগুলি বাদ দিয়ে৷

ইলাস্টিকসার্চ সহ ফুল: জাভা সেটআপ

এটিকে আমরা যেভাবে চেয়েছিলাম সেভাবে কাজ করার জন্য, আমরা ক্লাস্টারে বিভিন্ন ধরণের জিনিস ডিবাগ করার জন্য খুব দীর্ঘ সময় ব্যয় করেছি।

আবিষ্কৃত সমস্যার প্রথম অংশটি ইলাস্টিকসার্চে ডিফল্টরূপে জাভা যেভাবে পূর্ব-কনফিগার করা হয়েছে তার সাথে সম্পর্কিত ছিল।

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

দেখা গেল যে লুসিন সূচক একত্রিত হয় নিতম্বের বাইরে। এবং কন্টেইনারগুলি ব্যবহার করা সম্পদের পরিপ্রেক্ষিতে বেশ কঠোরভাবে সীমিত। শুধুমাত্র হিপগুলি এই সংস্থানগুলিতে ফিট করতে পারে (heap.size মানটি প্রায় RAM এর সমান ছিল), এবং কিছু অফ-হিপ অপারেশনগুলি একটি মেমরি বরাদ্দকরণ ত্রুটির সাথে ক্র্যাশ হয়েছিল যদি কোনও কারণে তারা সীমার আগে রয়ে যাওয়া ~500MB-এর সাথে ফিট না করে।

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

সমস্যা দুই
ক্লাস্টার চালু হওয়ার 4-5 দিন পরে, আমরা লক্ষ্য করেছি যে ডেটা নোডগুলি পর্যায়ক্রমে ক্লাস্টারের বাইরে পড়তে শুরু করে এবং 10-20 সেকেন্ড পরে এটি প্রবেশ করে।

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

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

সমাধানটি নিম্নরূপ ছিল: আমরা এই ক্রিয়াকলাপগুলির জন্য স্তূপের বাইরে মেমরির বেশির ভাগ ব্যবহার করার জন্য জাভার ক্ষমতা সীমিত করেছি। আমরা এটিকে 16 গিগাবাইটে সীমাবদ্ধ করেছি (-XX:MaxDirectMemorySize=16g), নিশ্চিত করে যে স্পষ্ট GC কে অনেক বেশি ঘন ঘন কল করা হয়েছে এবং অনেক দ্রুত প্রক্রিয়া করা হয়েছে, যার ফলে ক্লাস্টারটি আর অস্থিতিশীল হবে না।

সমস্যা তিন
আপনি যদি মনে করেন যে "সবচেয়ে অপ্রত্যাশিত মুহুর্তে ক্লাস্টার ছেড়ে যাওয়া নোড" এর সমস্যাগুলি শেষ হয়ে গেছে, আপনি ভুল করছেন।

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

এই আচরণ থেকে পরিত্রাণ পেতে, আমরা প্রথমে স্ট্যান্ডার্ড niofs-এ স্যুইচ করেছি, এবং তারপরে, যখন আমরা ইলাস্টিকের পঞ্চম সংস্করণ থেকে ষষ্ঠ সংস্করণে স্থানান্তরিত হয়েছি, আমরা হাইব্রিডএফের চেষ্টা করেছি, যেখানে এই সমস্যাটি পুনরুত্পাদন করা হয়নি। আপনি স্টোরেজ প্রকার সম্পর্কে আরও পড়তে পারেন এখানে.

সমস্যা চার
তারপরে আরেকটি খুব আকর্ষণীয় সমস্যা ছিল যা আমরা একটি রেকর্ড সময়ের জন্য চিকিত্সা করেছি। আমরা এটি 2-3 মাস ধরে ধরেছিলাম কারণ এর প্যাটার্নটি একেবারেই বোধগম্য ছিল।

কখনও কখনও আমাদের সমন্বয়কারীরা ফুল জিসি-তে যান, সাধারণত দুপুরের খাবারের পরে, এবং সেখান থেকে ফিরে আসেননি। একই সময়ে, GC দেরি লগ করার সময়, এটি এইরকম লাগছিল: সবকিছু ঠিকঠাক চলছে, ভাল, ভাল, এবং তারপরে হঠাৎ সবকিছু খুব খারাপভাবে চলছে।

প্রথমে আমরা ভেবেছিলাম যে আমাদের একজন দুষ্ট ব্যবহারকারী আছে যিনি এমন কিছু অনুরোধ শুরু করছেন যা সমন্বয়কারীকে কাজের মোড থেকে ছিটকে দিয়েছে। আমরা খুব দীর্ঘ সময়ের জন্য অনুরোধগুলি লগ করেছি, কী ঘটছে তা বোঝার চেষ্টা করেছি৷

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

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

এই পরিস্থিতিতে ক্লাস্টারের আচরণ পরিবর্তন করার একমাত্র সমাধান হল JDK13-এ স্থানান্তর এবং Shenandoah আবর্জনা সংগ্রহকারীর ব্যবহার। এটি সমস্যার সমাধান করেছে, আমাদের সমন্বয়কারীরা পড়া বন্ধ করেছে।

এখানেই জাভার সমস্যা শেষ হয়েছিল এবং ব্যান্ডউইথ সমস্যা শুরু হয়েছিল।

ইলাস্টিকসার্চ সহ "বেরি": থ্রুপুট

থ্রুপুট সমস্যা মানে আমাদের ক্লাস্টার স্থিরভাবে কাজ করে, কিন্তু সূচীকৃত নথির সংখ্যার শীর্ষে এবং কৌশলের সময়, কর্মক্ষমতা অপর্যাপ্ত।

প্রথম উপসর্গের সম্মুখীন হয়: উৎপাদনে কিছু "বিস্ফোরণের" সময়, যখন খুব বড় সংখ্যক লগ হঠাৎ করে তৈরি হয়, তখন গ্রেলগে ইনডেক্সিং ত্রুটি es_rejected_execution ঘন ঘন ফ্ল্যাশ হতে শুরু করে।

এটি একটি ডেটা নোডে thread_pool.write.queue এর কারণে হয়েছিল, যতক্ষণ না Elasticsearch ইনডেক্সিং অনুরোধ প্রক্রিয়া করতে সক্ষম হয় এবং ডিস্কের শার্ডে তথ্য আপলোড করতে সক্ষম হয়, ডিফল্টরূপে শুধুমাত্র 200টি অনুরোধ ক্যাশে করতে সক্ষম হয়। এবং ভিতরে ইলাস্টিক সার্চ ডকুমেন্টেশন এই প্যারামিটার সম্পর্কে খুব কম বলা হয়। শুধুমাত্র সর্বাধিক সংখ্যক থ্রেড এবং ডিফল্ট আকার নির্দেশিত হয়।

অবশ্যই, আমরা এই মানটিকে টুইস্ট করতে গিয়েছিলাম এবং নিম্নলিখিতগুলি খুঁজে পেয়েছি: বিশেষত, আমাদের সেটআপে, 300টি পর্যন্ত অনুরোধগুলি বেশ ভালভাবে ক্যাশে করা হয়েছে এবং একটি উচ্চতর মান এই সত্যে পরিপূর্ণ যে আমরা আবার সম্পূর্ণ GC-তে উড়ে যাই৷

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

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

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

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

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

পড়ার ছবি এইরকম দেখতে শুরু করে:

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

অবশেষে, মূল সমস্যাটি ছিল ডেটা সেন্টারের ব্যথাহীন অপসারণ।

এক ডিসির সাথে সংযোগ হারানোর সাথে সাথে আমরা ক্লাস্টার থেকে যা চেয়েছিলাম:

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

এটি পরিণত হয়েছে, আমরা এই মত কিছু চেয়েছিলাম:

এবং আমরা নিম্নলিখিত পেয়েছি:

এটা কিভাবে ঘটেছে?

ডেটা সেন্টার পড়ে গেলে, আমাদের মাস্টার বাধা হয়ে দাঁড়ায়।

কেন?

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

একটি ডেটা সেন্টার প্রত্যাহারের সময়, দেখা গেল যে বেঁচে থাকা ডেটা সেন্টারের সমস্ত ডেটা নোড মাস্টারকে জানানো তাদের কর্তব্য বলে মনে করেছিল "আমরা অমুক অমুক শার্ড এবং অমুক অমুক ডেটা নোড হারিয়েছি।"

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

টার্মিনাল আকারে, এটি প্রমাণিত হয়েছে যে ডেটা নোডগুলি মাস্টারকে এমনভাবে স্প্যাম করেছে যে এটি সম্পূর্ণ GC-তে চলে গেছে। এর পরে, আমাদের মাস্টার ভূমিকাটি পরবর্তী কিছু নোডে চলে গেছে, একেবারে একই জিনিসটি ঘটেছে এবং ফলস্বরূপ ক্লাস্টারটি সম্পূর্ণভাবে ভেঙে পড়েছে।

আমরা পরিমাপ নিয়েছিলাম, এবং সংস্করণ 6.4.0 এর আগে, যেখানে এটি ঠিক করা হয়েছিল, ক্লাস্টারটি সম্পূর্ণরূপে বন্ধ করার জন্য আমাদের জন্য একই সাথে 10 এর মধ্যে শুধুমাত্র 360টি ডেটা নোড আউটপুট করা যথেষ্ট ছিল।

এটি এই মত কিছু দেখাচ্ছিল:

সংস্করণ 6.4.0 এর পরে, যেখানে এই ভয়ানক বাগ সংশোধন করা হয়েছিল, ডেটা নোডগুলি মাস্টারকে হত্যা করা বন্ধ করে দিয়েছে। কিন্তু এটি তাকে "স্মার্ট" করেনি। যথা: যখন আমরা 2, 3 বা 10 (একটি ব্যতীত অন্য যেকোন সংখ্যা) ডেটা নোড আউটপুট করি, তখন মাস্টার প্রথম কিছু বার্তা পায় যা বলে যে নোড A চলে গেছে, এবং নোড বি, নোড সি এই সম্পর্কে, নোড ডি বলার চেষ্টা করে।

এবং এই মুহুর্তে, এটি কেবলমাত্র 20-30 সেকেন্ডের সমান, এবং এইভাবে ক্লাস্টার থেকে বেরিয়ে আসা ডেটা সেন্টারের গতি নিয়ন্ত্রণ করে কিছু সম্পর্কে কাউকে বলার চেষ্টার জন্য একটি সময়সীমা নির্ধারণ করে মোকাবেলা করা যেতে পারে।

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

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

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

ফলস্বরূপ, ভিড়ের সময় একটি ডেটা সেন্টার প্রত্যাহার করতে আমাদের প্রায় 5 মিনিট সময় লাগে। যেমন একটি বড় এবং আনাড়ি কলোসাস জন্য, এটি একটি চমত্কার ভাল ফলাফল.

ফলস্বরূপ, আমরা নিম্নলিখিত সিদ্ধান্তে এসেছি:

• আমাদের 360 গিগাবাইট ডিস্ক সহ 700 ডেটা নোড রয়েছে।
• এই একই ডেটা নোডের মাধ্যমে ট্র্যাফিক রাউটিং করার জন্য 60 সমন্বয়কারী।
• 40টি মাস্টার যা আমরা 6.4.0 এর আগের সংস্করণ থেকে এক ধরণের উত্তরাধিকার হিসাবে রেখে এসেছি - ডেটা সেন্টারের প্রত্যাহার থেকে বেঁচে থাকার জন্য, এমনকি মাস্টারদের একটি কোরাম থাকার নিশ্চয়তা দেওয়ার জন্য আমরা বেশ কয়েকটি মেশিন হারানোর জন্য মানসিকভাবে প্রস্তুত ছিলাম। সবচেয়ে খারাপ পরিস্থিতি
• একটি পাত্রে ভূমিকা একত্রিত করার যে কোনও প্রচেষ্টা এই সত্যের সাথে পূরণ হয়েছিল যে শীঘ্র বা পরে নোডটি লোডের মধ্যে ভেঙে যাবে।
• পুরো ক্লাস্টারটি 31 গিগাবাইটের একটি heap.size ব্যবহার করে: আকার কমানোর সমস্ত প্রচেষ্টার ফলে হয় নেতৃস্থানীয় ওয়াইল্ডকার্ডের সাহায্যে ভারী অনুসন্ধানের প্রশ্নে কিছু নোড মেরে ফেলা হয় বা ইলাস্টিকসার্চে নিজেই সার্কিট ব্রেকার পাওয়া যায়।
• উপরন্তু, অনুসন্ধান কার্যকারিতা নিশ্চিত করার জন্য, আমরা ক্লাস্টারে বস্তুর সংখ্যা যতটা সম্ভব ছোট রাখার চেষ্টা করেছি, যতটা সম্ভব কম ইভেন্ট প্রক্রিয়া করার জন্য যা আমরা মাস্টারে পেয়েছি।

অবশেষে মনিটরিং সম্পর্কে

এই সমস্ত উদ্দেশ্য হিসাবে কাজ করে তা নিশ্চিত করতে, আমরা নিম্নলিখিতগুলি পর্যবেক্ষণ করি:

• প্রতিটি ডেটা নোড আমাদের ক্লাউডকে রিপোর্ট করে যে এটি বিদ্যমান, এবং এটিতে অমুক এবং অমুক শার্ড রয়েছে। যখন আমরা কোথাও কিছু নিভিয়ে ফেলি, তখন ক্লাস্টারটি 2-3 সেকেন্ড পরে রিপোর্ট করে যে কেন্দ্র A-তে আমরা নোড 2, 3 এবং 4 নিভিয়ে দিয়েছি - এর মানে হল যে অন্যান্য ডেটা সেন্টারে আমরা কোনও অবস্থাতেই সেই নোডগুলিকে নিভিয়ে দিতে পারি না যেখানে শুধুমাত্র একটি শার্ড রয়েছে। বাম
• মাস্টারের আচরণের প্রকৃতি জেনে, আমরা মুলতুবি থাকা কাজের সংখ্যা খুব মনোযোগ সহকারে দেখি। কারণ এমনকি একটি আটকে থাকা কাজ, যদি এটি সময়মতো শেষ না হয়, তাত্ত্বিকভাবে কিছু জরুরী পরিস্থিতিতে কারণ হয়ে উঠতে পারে, উদাহরণস্বরূপ, প্রাথমিকে একটি রেপ্লিকা শার্ডের প্রচার কাজ করে না, যার কারণে ইন্ডেক্সিং কাজ করা বন্ধ করে দেবে।
• আমরা আবর্জনা সংগ্রহকারী বিলম্বের দিকেও খুব ঘনিষ্ঠভাবে নজর রাখি, কারণ অপ্টিমাইজেশনের সময় আমরা ইতিমধ্যেই এটির সাথে অনেক সমস্যায় পড়েছি।
• অগ্রিম বুঝতে থ্রেড দ্বারা প্রত্যাখ্যান যেখানে বাধা আছে.
• ভাল, স্ট্যান্ডার্ড মেট্রিক্স যেমন হিপ, RAM এবং I/O।

মনিটরিং তৈরি করার সময়, আপনাকে অবশ্যই ইলাস্টিকসার্চে থ্রেড পুলের বৈশিষ্ট্যগুলি বিবেচনা করতে হবে। ইলাস্টিক সার্চ ডকুমেন্টেশন অনুসন্ধান এবং সূচীকরণের জন্য কনফিগারেশন বিকল্প এবং ডিফল্ট মানগুলি বর্ণনা করে, কিন্তু thread_pool.management সম্বন্ধে সম্পূর্ণ নীরব। এই থ্রেডগুলি প্রক্রিয়া করে, বিশেষ করে, _cat/shards এবং অন্যান্য অনুরূপ প্রশ্নগুলির মতো, যা পর্যবেক্ষণ লেখার সময় ব্যবহার করা সুবিধাজনক। ক্লাস্টার যত বড় হবে, সময়ের প্রতি ইউনিটে এই ধরনের অনুরোধগুলি তত বেশি কার্যকর করা হবে, এবং উপরে উল্লিখিত thread_pool.management শুধুমাত্র অফিসিয়াল ডকুমেন্টেশনে উপস্থাপিত হয় না, তবে এটি ডিফল্টরূপে 5টি থ্রেডের মধ্যে সীমাবদ্ধ থাকে, যা খুব দ্রুত নিষ্পত্তি করা হয়, পরে যা মনিটরিং সঠিকভাবে কাজ করা বন্ধ করে দেয়।

আমি উপসংহারে যা বলতে চাই: আমরা এটি করেছি! আমরা আমাদের প্রোগ্রামার এবং ডেভেলপারদের এমন একটি টুল দিতে সক্ষম হয়েছি যা প্রায় যেকোনো পরিস্থিতিতেই উৎপাদনে কী ঘটছে সে সম্পর্কে দ্রুত এবং নির্ভরযোগ্যভাবে তথ্য প্রদান করতে পারে।

হ্যাঁ, এটি বেশ জটিল হয়ে উঠল, তবে, তবুও, আমরা আমাদের ইচ্ছাগুলিকে বিদ্যমান পণ্যগুলিতে ফিট করতে পেরেছি, যা আমাদের নিজেদের জন্য প্যাচ এবং পুনরায় লিখতে হবে না।

উত্স: www.habr.com