প্রচুর ফ্রি RAM, NVMe Intel P4500 এবং সবকিছুই অত্যন্ত ধীর - একটি অদলবদল পার্টিশনের ব্যর্থ সংযোজনের গল্প

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

প্রস্তাবনা

আমরা একটি মাঝারি আকারের ক্লাউড পরিচালনা করি, যা আমরা নিম্নলিখিত কনফিগারেশন সহ স্ট্যান্ডার্ড সার্ভারগুলিতে তৈরি করি - 32 কোর, 256 GB RAM এবং একটি 4500TB PCI-E Intel P4 NVMe ড্রাইভ৷ আমরা সত্যিই এই কনফিগারেশনটি পছন্দ করি কারণ এটি VM ইনস্ট্যান্স টাইপ স্তরে সঠিক সীমাবদ্ধতা প্রদান করে IO ওভারহেড সম্পর্কে চিন্তা করার প্রয়োজনীয়তা দূর করে। কারণ এনভিএমই ইন্টেল P4500 চিত্তাকর্ষক কর্মক্ষমতা রয়েছে, আমরা একই সাথে শূন্য IOWAIT সহ একটি ব্যাকআপ সার্ভারে মেশিনে সম্পূর্ণ IOPS প্রভিশনিং এবং ব্যাকআপ স্টোরেজ উভয়ই প্রদান করতে পারি।

আমরা সেই পুরানো বিশ্বাসীদের মধ্যে একজন যারা হাইপারকনভার্জড SDN এবং অন্যান্য স্টাইলিশ, ফ্যাশনেবল, যুবক জিনিসগুলি VM ভলিউমগুলি সঞ্চয় করার জন্য ব্যবহার করি না, বিশ্বাস করে যে সিস্টেম যত সহজ, "প্রধান গুরু চলে গেছে" এর শর্তে এটির সমস্যা সমাধান করা তত সহজ পর্বতের দিকে." ফলস্বরূপ, আমরা XFS বা EXT2-এ QCOW4 ফর্ম্যাটে VM ভলিউম সংরক্ষণ করি, যা LVM2 এর উপরে স্থাপন করা হয়।

আমরা অর্কেস্ট্রেশনের জন্য যে পণ্যটি ব্যবহার করি তার দ্বারা আমরা QCOW2 ব্যবহার করতে বাধ্য হই - Apache CloudStack।

একটি ব্যাকআপ সঞ্চালন করার জন্য, আমরা একটি LVM2 স্ন্যাপশট হিসাবে ভলিউমের একটি সম্পূর্ণ চিত্র গ্রহণ করি (হ্যাঁ, আমরা জানি যে LVM2 স্ন্যাপশটগুলি ধীর, কিন্তু Intel P4500 আমাদের এখানেও সাহায্য করে)। আমরা করি lvmcreate -s .. এবং সাহায্যে dd আমরা ZFS স্টোরেজ সহ একটি রিমোট সার্ভারে ব্যাকআপ কপি পাঠাই। এখানে আমরা এখনও কিছুটা প্রগতিশীল - সর্বোপরি, ZFS সংকুচিত আকারে ডেটা সংরক্ষণ করতে পারে এবং আমরা এটি ব্যবহার করে দ্রুত পুনরুদ্ধার করতে পারি DD অথবা ব্যবহার করে পৃথক VM ভলিউম পান mount -o loop ....

আপনি, অবশ্যই, LVM2 ভলিউমের সম্পূর্ণ চিত্রটি সরাতে পারবেন না, তবে ফাইল সিস্টেমটি মাউন্ট করতে পারেন RO এবং QCOW2 চিত্রগুলি নিজেরাই অনুলিপি করুন, যাইহোক, আমরা এই সত্যটির মুখোমুখি হয়েছিলাম যে এটি থেকে XFS খারাপ হয়ে গেছে, এবং অবিলম্বে নয়, একটি অপ্রত্যাশিত উপায়ে। আমরা সত্যিই এটি পছন্দ করি না যখন হাইপারভাইজার সপ্তাহান্তে, রাতে বা ছুটির দিনে হঠাৎ "লাঠি" হোস্ট করে এমন ত্রুটির কারণে যা কখন ঘটবে তা স্পষ্ট নয়। তাই, XFS-এর জন্য আমরা স্ন্যাপশট মাউন্টিং মোড ব্যবহার করি না RO ভলিউম নিষ্কাশন করতে, আমরা কেবলমাত্র সম্পূর্ণ LVM2 ভলিউম অনুলিপি করি।

ব্যাকআপ সার্ভারে ব্যাকআপের গতি আমাদের ক্ষেত্রে ব্যাকআপ সার্ভারের কর্মক্ষমতা দ্বারা নির্ধারিত হয়, যা প্রায় 600-800 MB/s হয় অসংকোচযোগ্য ডেটার জন্য; আরও সীমাবদ্ধতা হল 10Gbit/s চ্যানেল যার সাথে ব্যাকআপ সার্ভার সংযুক্ত থাকে ক্লাস্টারে

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

উপরের কপি করার প্রক্রিয়াটি বিস্তারিত সহ আরও গল্পের জন্য খুবই গুরুত্বপূর্ণ - একটি দ্রুত Intel P4500 ড্রাইভ ব্যবহার করে, NFS ব্যবহার করে এবং সম্ভবত, ZFS ব্যবহার করে।

ব্যাকআপ গল্প

প্রতিটি হাইপারভাইজার নোডে আমাদের 8 গিগাবাইটের আকারের একটি ছোট SWAP পার্টিশন রয়েছে এবং আমরা হাইপারভাইজার নোড ব্যবহার করে নিজেই "রোল আউট" করি। DD রেফারেন্স ইমেজ থেকে। সার্ভারে সিস্টেম ভলিউমের জন্য, আমরা LSI বা HP হার্ডওয়্যার কন্ট্রোলারে 2xSATA SSD RAID1 বা 2xSAS HDD RAID1 ব্যবহার করি। সাধারণভাবে, ভিতরে যা আছে তা আমরা মোটেই চিন্তা করি না, যেহেতু আমাদের সিস্টেম ভলিউম SWAP বাদে "প্রায় শুধুমাত্র পঠনযোগ্য" মোডে কাজ করে। এবং যেহেতু আমাদের সার্ভারে প্রচুর RAM আছে এবং এটি 30-40% বিনামূল্যে, আমরা SWAP সম্পর্কে চিন্তা করি না।

ব্যাকআপ প্রক্রিয়া. এই কাজটি এরকম কিছু দেখায়:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

মনোযোগ দিন ionice -c3, আসলে, এই জিনিসটি NVMe ডিভাইসগুলির জন্য সম্পূর্ণরূপে অকেজো, যেহেতু তাদের জন্য IO সময়সূচী এইভাবে সেট করা হয়েছে:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

যাইহোক, আমাদের কাছে প্রচলিত SSD RAID সহ বেশ কয়েকটি লিগ্যাসি নোড রয়েছে, তাদের জন্য এটি প্রাসঙ্গিক, তাই তারা সরে যাচ্ছে AS IS. সামগ্রিকভাবে, এটি কোডের একটি আকর্ষণীয় অংশ যা অসারতা ব্যাখ্যা করে ionice যেমন একটি কনফিগারেশন ক্ষেত্রে.

পতাকার দিকে মনোযোগ দিন iflag=direct থেকে DD. পড়ার সময় IO বাফারের অপ্রয়োজনীয় প্রতিস্থাপন এড়াতে আমরা বাফার ক্যাশে বাইপাস করে সরাসরি IO ব্যবহার করি। যাহোক, oflag=direct আমরা না কারণ এটি ব্যবহার করার সময় আমরা ZFS কর্মক্ষমতা সমস্যার সম্মুখীন হয়েছি।

আমরা সমস্যা ছাড়াই বেশ কয়েক বছর ধরে সফলভাবে এই স্কিমটি ব্যবহার করে আসছি।

এবং তারপর এটি শুরু হয়... আমরা আবিষ্কার করেছি যে একটি নোড আর ব্যাক আপ করা হয়নি, এবং আগেরটি 50% এর একটি দানবীয় IOWAIT এর সাথে চলছিল। অনুলিপি কেন ঘটে না তা বোঝার চেষ্টা করার সময়, আমরা নিম্নলিখিত ঘটনার সম্মুখীন হয়েছি:

Volume group "images" not found

আমরা "Intel P4500 এর সমাপ্তি এসেছে" সম্পর্কে ভাবতে শুরু করেছি, তবে, ড্রাইভটি প্রতিস্থাপন করার জন্য সার্ভারটি বন্ধ করার আগে, এটি এখনও একটি ব্যাকআপ সঞ্চালন করা প্রয়োজন ছিল৷ আমরা একটি LVM2 ব্যাকআপ থেকে মেটাডেটা পুনরুদ্ধার করে LVM2 ঠিক করেছি:

vgcfgrestore images

আমরা একটি ব্যাকআপ চালু করেছি এবং এই তেল চিত্রটি দেখেছি:

আবার আমরা খুব দু: খিত ছিলাম - এটা পরিষ্কার যে আমরা এভাবে বাঁচতে পারি না, যেহেতু সমস্ত ভিপিএস ক্ষতিগ্রস্থ হবে, যার অর্থ আমরাও কষ্ট পাব। কি ঘটেছে সম্পূর্ণরূপে অস্পষ্ট - iostat করুণ IOPS এবং সর্বোচ্চ IOWAIT দেখিয়েছে। "আসুন NVMe প্রতিস্থাপন করা যাক" ছাড়া অন্য কোন ধারণা ছিল না, কিন্তু ঠিক সময়ে একটি অন্তর্দৃষ্টি ঘটেছে।

ধাপে ধাপে পরিস্থিতি বিশ্লেষণ

ঐতিহাসিক পত্রিকা. কিছু দিন আগে, এই সার্ভারে 128 GB RAM সহ একটি বড় VPS তৈরি করা প্রয়োজন ছিল। যথেষ্ট মেমরি আছে বলে মনে হচ্ছে, কিন্তু নিরাপদে থাকার জন্য, আমরা অদলবদল পার্টিশনের জন্য আরও 32 জিবি বরাদ্দ করেছি। ভিপিএস তৈরি করা হয়েছিল, সফলভাবে এর কাজটি সম্পন্ন হয়েছে এবং ঘটনাটি ভুলে গেছে, কিন্তু SWAP পার্টিশনটি রয়ে গেছে।

কনফিগারেশন বৈশিষ্ট্য. সমস্ত ক্লাউড সার্ভারের জন্য পরামিতি vm.swappiness ডিফল্ট হিসাবে সেট করা হয়েছিল 60. এবং SWAP SAS HDD RAID1 এ তৈরি করা হয়েছিল।

কি ঘটেছে (সম্পাদকদের মতে). ব্যাক আপ করার সময় DD NFS-এ লেখার আগে RAM বাফারে স্থাপন করা হয়েছিল। সিস্টেম কোর, নীতি দ্বারা পরিচালিত swappiness, ভিপিএস মেমরির অনেক পৃষ্ঠা সোয়াপ এলাকায় সরানো হচ্ছে, যা একটি ধীর HDD RAID1 ভলিউমে অবস্থিত ছিল। এর ফলে IOWAIT খুব জোরালোভাবে বেড়েছে, কিন্তু IO NVMe এর কারণে নয়, IO HDD RAID1 এর কারণে।

কিভাবে সমস্যা সমাধান করা হয়েছে. 32GB সোয়াপ পার্টিশন নিষ্ক্রিয় করা হয়েছে। এটি 16 ঘন্টা সময় নিয়েছে; কিভাবে এবং কেন SWAP এত ধীরে ধীরে বন্ধ হয় সে সম্পর্কে আপনি আলাদাভাবে পড়তে পারেন। সেটিংস পরিবর্তন করা হয়েছে swappiness একটি মান সমান 5 সমস্ত মেঘ জুড়ে।

এটা কিভাবে ঘটতে পারে না?. প্রথমত, যদি SWAP একটি SSD RAID বা NVMe ডিভাইসে থাকত এবং দ্বিতীয়ত, NVMe ডিভাইস না থাকলে, কিন্তু একটি ধীর ডিভাইস যা এত পরিমাণ ডেটা তৈরি করবে না - হাস্যকরভাবে, সমস্যাটি ঘটেছে কারণ NVMe খুব দ্রুত।

এর পরে, সবকিছু আগের মতো কাজ করতে শুরু করে - শূন্য IOWAIT দিয়ে।

উত্স: www.habr.com