ڪاسندرا جي لڏپلاڻ ڪبرنيٽس ڏانهن: خاصيتون ۽ حل

اسان باقاعدي طور تي Apache Cassandra ڊيٽابيس ۽ ان کي ڪم ڪرڻ جي ضرورت سان منهن ڏيون ٿا ڪبرنيٽس جي بنياد تي انفراسٽرڪچر. هن مواد ۾، اسان Cassandra کان K8s ڏانهن لڏپلاڻ لاءِ ضروري قدمن، معيارن ۽ موجوده حلن (بشمول آپريٽرن جو جائزو) بابت اسان جي نظريي کي شيئر ڪنداسين.

”جيڪو عورت تي حڪومت ڪري سگهي ٿو اهو رياست تي به حڪومت ڪري سگهي ٿو“

Cassandra ڪير آهي؟ اهو هڪ ورهايل اسٽوريج سسٽم آهي جيڪو ڊيٽا جي وڏي مقدار کي منظم ڪرڻ لاءِ ٺهيل آهي جڏهن ته ناڪامي جي هڪ نقطي کان سواءِ اعليٰ دستيابي کي يقيني بڻائي ٿي. پروجيڪٽ کي مشڪل سان هڪ ڊگهي تعارف جي ضرورت آهي، تنهنڪري مان صرف Cassandra جي مکيه خاصيتون ڏيندس جيڪي هڪ خاص مضمون جي حوالي سان لاڳاپيل هوندا:

• Cassandra جاوا ۾ لکيل آهي.
• Cassandra ٽوپولوجي ۾ ڪيترن ئي سطحن تي مشتمل آهي:
  • نوڊ - ھڪڙي ترتيب ڏنل Cassandra مثال؛
  • ريڪ Cassandra مثالن جو هڪ گروپ آهي، جيڪو ڪجهه خاصيتن سان متحد آهي، ساڳئي ڊيٽا سينٽر ۾ واقع آهي.
  • Datacenter - هڪ ڊيٽا سينٽر ۾ واقع Cassandra مثالن جي سڀني گروپن جو مجموعو؛
  • ڪلستر سڀني ڊيٽا سينٽرن جو هڪ مجموعو آهي.
• Cassandra هڪ IP پتو استعمال ڪري ٿو هڪ نوڊ جي سڃاڻپ ڪرڻ لاء.
• لکڻ ۽ پڙهڻ جي عملن کي تيز ڪرڻ لاءِ، ڪئاسندرا ڪجهه ڊيٽا کي رام ۾ محفوظ ڪري ٿو.

ھاڻي - ڪبرنيٽس ڏانھن حقيقي امڪاني منتقل ڪرڻ لاء.

منتقلي لاءِ چيڪ لسٽ

ڪاسندرا جي لڏپلاڻ بابت ڪبرنيٽس جي باري ۾ ڳالهائيندي، اسان کي اميد آهي ته منتقل ٿيڻ سان ان کي منظم ڪرڻ لاء وڌيڪ آسان ٿيندو. ان لاءِ ڪهڙي ضرورت پوندي، ان ۾ ڪهڙي مدد ملندي؟

1. ڊيٽا اسٽوريج

جيئن ته اڳ ۾ ئي واضح ڪيو ويو آهي، Cassanda ڊيٽا جو حصو RAM-in ۾ محفوظ ڪري ٿو يادگار. پر ڊيٽا جو هڪ ٻيو حصو آهي جيڪو ڊسڪ ۾ محفوظ ڪيو ويو آهي - فارم ۾ ايس ايس ٽيبل. ھن ڊيٽا ۾ ھڪڙو ادارو شامل ڪيو ويو آھي ڪمٽ لاگ - سڀني ٽرانزيڪشن جا رڪارڊ، جيڪي پڻ ڊسڪ ۾ محفوظ ڪيا ويا آهن.

Cassandra ۾ ٽرانزيڪشن آريگرام لکو

Kubernetes ۾، اسان ڊيٽا کي ذخيرو ڪرڻ لاء PersistentVolume استعمال ڪري سگھون ٿا. ثابت ڪيل ميڪانيزم جي مهرباني، ڪبرنيٽس ۾ ڊيٽا سان ڪم ڪرڻ هر سال آسان ٿي رهيو آهي.

اسان هر Cassandra پوڊ لاءِ پنهنجو پنهنجو Persistent Volume مختص ڪنداسين

اهو نوٽ ڪرڻ ضروري آهي ته Cassandra خود ڊيٽا جي نقل جو مطلب آهي، هن لاء ٺهيل ميڪانيزم پيش ڪري ٿو. تنهن ڪري، جيڪڏهن توهان وڏي تعداد ۾ نوڊس مان هڪ Cassandra ڪلستر ٺاهي رهيا آهيو، پوء ڊيٽا اسٽوريج لاء ڪيف يا GlusterFS وانگر ورهايل سسٽم استعمال ڪرڻ جي ڪا ضرورت ناهي. انهي صورت ۾، اهو منطقي هوندو ته هوسٽ ڊسڪ تي ڊيٽا کي ذخيرو ڪرڻ لاء استعمال ڪندي مقامي مسلسل ڊسڪ يا چڙهڻ hostPath.

ٻيو سوال اهو آهي ته جيڪڏهن توهان چاهيو ٿا ته ڊولپرز لاءِ هڪ الڳ ماحول ٺاهيو هر فيچر برانچ لاءِ. انهي صورت ۾، صحيح طريقي سان هڪ ڪئاسندرا نوڊ کي وڌائڻ ۽ ڊيٽا کي ورهايل اسٽوريج ۾ ذخيرو ڪرڻ، يعني. ذڪر ڪيل Ceph ۽ GlusterFS توهان جا اختيار هوندا. پوءِ ڊولپر کي پڪ ٿي ويندي ته هو ٽيسٽ ڊيٽا نه وڃائيندو جيتوڻيڪ ڪوبرنٽس ڪلستر نوڊس مان هڪ گم ٿي ويو آهي.

2. نگراني

ڪبرنيٽس ۾ مانيٽرنگ کي لاڳو ڪرڻ لاءِ عملي طور تي اڻ کٽيل انتخاب Prometheus آهي (اسان ان بابت تفصيل سان ڳالهايو لاڳاپيل رپورٽ). پروميٿيوس لاءِ ميٽرڪس ايڪسپورٽرز سان ڪئاسندرا ڪيئن ڪري رهي آهي؟ ۽، ڇا اڃا وڌيڪ اهم آهي، گرافانا لاءِ ڊيش بورڊ سان ملندڙ؟

Cassandra لاء Grafana ۾ گراف جي ظاهر جو هڪ مثال

هتي صرف ٻه برآمد ڪندڙ آهن: jmx_exporter и cassandra_exporter.

اسان پنهنجي لاء پهريون چونڊيو ڇو ته:

1. JMX ايڪسپورٽ وڌي رهيو آهي ۽ ترقي ڪري رهيو آهي، جڏهن ته Cassandra ايڪسپورٽ ڪافي ڪميونٽي جي مدد حاصل ڪرڻ جي قابل نه آهي. Cassandra ايڪسپورٽ اڃا تائين Cassandra جي اڪثر نسخن کي سپورٽ نٿو ڪري.
2. توھان ان کي هلائي سگھوٿا جاوا ايجنٽ طور جھنڊو شامل ڪندي -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. هن لاء هڪ آهي مناسب ڊيش بورڊ, جيڪو Cassandra Exporter سان گڏ نامناسب آهي.

3. Kubernetes primitives چونڊيو

Cassandra ڪلستر جي مٿين ساخت جي مطابق، اچو ته هر شي کي ترجمو ڪرڻ جي ڪوشش ڪريون جيڪي اتي بيان ڪيل آهن ڪبرنيٽس اصطلاحات ۾:

• Cassandra Node → Pod
• Cassandra ريڪ → StatefulSet
• Cassandra Datacenter → Pool from StatefulSets
• Cassandra ڪلستر → ؟؟؟

اهو ظاهر ٿئي ٿو ته ڪجهه اضافي ادارو غائب آهي هڪ ڀيرو سڄي Cassandra ڪلستر کي منظم ڪرڻ لاء. پر جيڪڏهن ڪا شيء موجود ناهي، اسان ان کي ٺاهي سگهون ٿا! ڪبرنيٽس وٽ هن مقصد لاءِ پنهنجي وسيلن جي وضاحت لاءِ هڪ ميکانيزم آهي. حسب ضرورت وسيلن جي وصف.

لاگ ۽ الرٽ لاء اضافي وسيلن جو اعلان

پر ڪسٽم ريسورس پاڻ کي ڪجھ به نه مطلب آهي: سڀ کان پوء، ان جي ضرورت آهي ڪنٽرولر. توھان کي شايد مدد طلب ڪرڻ جي ضرورت پوندي ڪبرنيٽس آپريٽر...

4. پوڊ جي سڃاڻپ

مٿين پيراگراف ۾، اسان اتفاق ڪيو ته هڪ ڪئاسندرا نوڊ ڪبرنيٽس ۾ هڪ پوڊ جي برابر هوندو. پر پوڊ جا IP پتي هر ڀيري مختلف هوندا. ۽ Cassandra ۾ هڪ نوڊ جي سڃاڻپ IP پتي تي ٻڌل آهي ... اهو ظاهر ٿئي ٿو ته هر هڪ پوڊ کي هٽائڻ کان پوء، Cassandra ڪلستر هڪ نئون نوڊ شامل ڪندو.

اتي ھڪڙو رستو آھي، ۽ صرف ھڪڙو نه آھي:

1. اسان رڪارڊ رکي سگھون ٿا ميزبان جي سڃاڻپ ڪندڙ (UUIDs جيڪي منفرد طور تي Cassandra مثالن جي سڃاڻپ ڪن ٿا) يا IP پتي ذريعي ۽ اهو سڀ ڪجهه ڪجهه جوڙجڪ/ٽيبلز ۾ محفوظ ڪري سگهون ٿا. هن طريقي جا ٻه مکيه نقصان آهن:
   • هڪ نسل جي حالت جو خطرو جيڪڏهن ٻه نوڊس هڪ ئي وقت ۾ گر ٿي وڃن. اڀار کان پوء، Cassandra نوڊس هڪ ئي وقت ٽيبل مان هڪ IP پتي جي درخواست ڪندو ۽ ساڳئي وسيلن لاء مقابلو ڪندو.
   • جيڪڏهن هڪ Cassandra نوڊ پنهنجي ڊيٽا وڃائي ڇڏيو آهي، اسان ان کي وڌيڪ سڃاڻڻ جي قابل نه هوندا.
2. ٻيو حل هڪ ننڍڙو هيڪ وانگر لڳي ٿو، پر ان جي باوجود: اسان هر Cassandra نوڊ لاء ClusterIP سان هڪ خدمت ٺاهي سگهون ٿا. هن عمل سان مسئلا:
   • جيڪڏهن ڪيسينڊرا ڪلستر ۾ ڪيترائي نوڊس آهن، اسان کي تمام گهڻيون خدمتون ٺاهڻ گهرجن.
   • ClusterIP خصوصيت iptables ذريعي لاڳو ڪئي وئي آهي. اهو هڪ مسئلو ٿي سگهي ٿو جيڪڏهن Cassandra ڪلستر ۾ ڪيترائي (1000 ... يا 100؟) نوڊس آهن. جيتوڻيڪ IPVS جي بنياد تي توازن هن مسئلي کي حل ڪري سگهي ٿو.
3. ٽيون حل اهو آهي ته سيٽنگ کي فعال ڪندي پوڊس جي وقف ٿيل نيٽ ورڪ جي بدران ڪيسندرا نوڊس لاءِ نوڊس جو نيٽ ورڪ استعمال ڪيو وڃي. hostNetwork: true. اهو طريقو ڪجهه حدن کي لاڳو ڪري ٿو:
   • يونٽن کي تبديل ڪرڻ لاء. اهو ضروري آهي ته نئين نوڊ کي ساڳيو IP پتو هجڻ گهرجي جيئن اڳئين هڪ (بادل جهڙوڪ AWS، GCP ۾ اهو ڪرڻ تقريبا ناممڪن آهي)؛
   • ڪلستر نوڊس جي نيٽ ورڪ کي استعمال ڪندي، اسان نيٽ ورڪ وسيلن لاء مقابلو ڪرڻ شروع ڪيو. تنهن ڪري، هڪ ڪلستر نوڊ تي Cassandra سان هڪ کان وڌيڪ پوڊ رکڻ مشڪل ٿي ويندو.

5. بيڪ اپ

اسان هڪ شيڊول تي هڪ واحد Cassandra نوڊ جي ڊيٽا جو مڪمل نسخو محفوظ ڪرڻ چاهيون ٿا. Kubernetes استعمال ڪندي هڪ آسان خصوصيت مهيا ڪري ٿي ڪرون جاب، پر هتي ڪئسندرا پاڻ اسان جي ڦيٿي ۾ هڪ ڳالهه رکي ٿي.

مون کي توهان کي ياد ڏياريو ته Cassandra ڪجهه ڊيٽا کي ميموري ۾ محفوظ ڪري ٿو. مڪمل بيڪ اپ ڪرڻ لاءِ، توھان کي ميموري مان ڊيٽا جي ضرورت آھي (يادگار) ڊسڪ ڏانهن منتقل (SSTables). هن نقطي تي، Cassandra نوڊ ڪنيڪشن کي قبول ڪرڻ بند ڪري ٿو، مڪمل طور تي ڪلستر کان بند ڪري ٿو.

ان کان پوء، بيڪ اپ هٽايو ويو آهي (اسپيڊ شاٽ) ۽ اسڪيم بچايو ويو (ڪي اسپيس). ۽ پوء اهو ظاهر ٿئي ٿو ته صرف هڪ بيڪ اپ اسان کي ڪجهه به نه ڏيندو آهي: اسان کي ڊيٽا جي سڃاڻپ ڪندڙ کي بچائڻ جي ضرورت آهي جنهن لاء Cassandra نوڊ ذميوار هو - اهي خاص ٽوڪن آهن.

ٽوڪن جي ورڇ سڃاڻڻ لاءِ ته ڪھڙي ڊيٽا ڪيسندرا نوڊس جا ذميوار آھن

ڪبرنيٽس ۾ گوگل کان ڪئاسندرا بيڪ اپ وٺڻ لاءِ هڪ مثال اسڪرپٽ ملي سگهي ٿو هي ڪڙي. صرف هڪ نقطو جيڪو اسڪرپٽ اڪائونٽ ۾ نٿو رکي، سنيپ شاٽ وٺڻ کان پهريان نوڊ ڏانهن ڊيٽا کي ري سيٽ ڪرڻ آهي. اهو آهي، بيڪ اپ موجوده رياست لاء نه، پر هڪ رياست لاء ٿورو اڳ ڪيو ويو آهي. پر هي مدد ڪري ٿو نوڊ کي آپريشن کان ٻاهر نه وٺي، جيڪو تمام منطقي لڳي ٿو.

set -eu

if [[ -z "$1" ]]; then
  info "Please provide a keyspace"
  exit 1
fi

KEYSPACE="$1"

result=$(nodetool snapshot "${KEYSPACE}")

if [[ $? -ne 0 ]]; then
  echo "Error while making snapshot"
  exit 1
fi

timestamp=$(echo "$result" | awk '/Snapshot directory: / { print $3 }')

mkdir -p /tmp/backup

for path in $(find "/var/lib/cassandra/data/${KEYSPACE}" -name $timestamp); do
  table=$(echo "${path}" | awk -F "[/-]" '{print $7}')
  mkdir /tmp/backup/$table
  mv $path /tmp/backup/$table
done


tar -zcf /tmp/backup.tar.gz -C /tmp/backup .

nodetool clearsnapshot "${KEYSPACE}"

هڪ بش اسڪرپٽ جو هڪ مثال هڪ ڪئاسندرا نوڊ مان بيڪ اپ وٺڻ لاءِ

Kubernetes ۾ Cassandra لاء تيار حل

ڪبرنيٽس ۾ ڪئاسندرا کي ترتيب ڏيڻ لاءِ في الحال ڇا استعمال ڪيو ويو آهي ۽ انهن مان ڪهڙو بهترين مناسب آهي ڏنل گهرجن؟

1. StatefulSet يا Helm چارٽ جي بنياد تي حل

Cassandra ڪلستر کي هلائڻ لاءِ بنيادي StatefulSets افعال استعمال ڪرڻ سٺو اختيار آھي. هيلم چارٽ ۽ گو ٽيمپليٽس استعمال ڪندي، توهان استعمال ڪندڙ کي مهيا ڪري سگهو ٿا هڪ لچڪدار انٽرفيس سان Cassandra کي ترتيب ڏيڻ لاءِ.

اهو عام طور تي ٺيڪ ڪم ڪري ٿو ... جيستائين ڪجهه غير متوقع ٿئي ٿو، جهڙوڪ نوڊ ناڪامي. معياري Kubernetes اوزار صرف مٿي بيان ڪيل سڀني خاصيتن کي حساب ۾ نٿا وٺي سگهن. اضافي طور تي، اهو طريقو تمام محدود آهي ان ۾ ڪيترو وڌائي سگهجي ٿو وڌيڪ پيچيده استعمالن لاءِ: نوڊ متبادل، بيڪ اپ، وصولي، نگراني، وغيره.

نمائندا:

• مکيه هيلم مخزن مان چارٽ;
• bitnami کان چارٽ.

ٻئي چارٽ هڪجهڙا سٺا آهن، پر مٿي بيان ڪيل مسئلن جي تابع آهن.

2. Kubernetes آپريٽر جي بنياد تي حل

اهڙا اختيار وڌيڪ دلچسپ آهن ڇو ته اهي ڪلستر کي منظم ڪرڻ لاء ڪافي موقعا فراهم ڪن ٿا. Cassandra آپريٽر کي ڊزائين ڪرڻ لاء، ڪنهن ٻئي ڊيٽابيس وانگر، هڪ سٺو نمونو ڏسڻ جهڙو آهي Sidecar <-> ڪنٽرولر <-> CRD:

نوڊ مينيجمينٽ اسڪيم هڪ چڱي طرح ٺهيل Cassandra آپريٽر ۾

اچو ته موجوده آپريٽرز کي ڏسو.

1. Cassandra-آپريٽر instaclustr کان

• GitHub
• تياري: الفا
• لائسنس: Apache 2.0
• لاڳو ٿيل ۾: Java

اهو واقعي هڪ ڪمپني مان هڪ تمام پرجوش ۽ فعال طور تي ترقي ڪندڙ منصوبو آهي جيڪو پيش ڪري ٿو منظم ڪيل ڪئاسندرا جي ترتيب. اهو، جيئن مٿي بيان ڪيو ويو آهي، هڪ سائڊ ڪار ڪنٽينر استعمال ڪري ٿو جيڪو HTTP ذريعي حڪم قبول ڪري ٿو. جاوا ۾ لکيل، اهو ڪڏهن ڪڏهن ڪلائنٽ-گو لائبريري جي وڌيڪ جديد ڪارڪردگي جي کوٽ ناهي. انهي سان گڏ، آپريٽر هڪ ڊيٽا سينٽر لاء مختلف ريڪ کي سپورٽ نٿو ڪري.

پر آپريٽر وٽ اهڙا فائدا آهن جيئن مانيٽرنگ لاءِ سپورٽ، CRD استعمال ڪندي اعليٰ سطحي ڪلسٽر مئنيجمينٽ، ۽ بيڪ اپ ٺاهڻ لاءِ به دستاويز.

2. Jetstack کان نيويگيٽر

• GitHub
• تياري: الفا
• لائسنس: Apache 2.0
• ۾ لاڳو ٿيل: گولانگ

ڊي بي-جي-هڪ-سروس کي ترتيب ڏيڻ لاءِ ٺهيل بيان. في الحال ٻن ڊيٽابيس کي سپورٽ ڪري ٿو: Elasticsearch ۽ Cassandra. ان وٽ اهڙا دلچسپ حل آهن جيئن RBAC ذريعي ڊيٽابيس تائين رسائي ڪنٽرول (ان لاءِ ان جو پنهنجو الڳ نيويگيٽر-اپيسرور آهي). هڪ دلچسپ منصوبو جيڪو هڪ ويجهي نظر وٺڻ جي قابل هوندو، پر آخري انجام هڪ اڌ سال اڳ ڪيو ويو، جيڪو واضح طور تي ان جي صلاحيت کي گهٽائي ٿو.

3. Cassandra-آپريٽر طرفان vgkowski

• GitHub
• تياري: الفا
• لائسنس: Apache 2.0
• ۾ لاڳو ٿيل: گولانگ

انهن ان تي غور نه ڪيو "سنجيده"، ڇاڪاڻ ته مخزن جي آخري وابستگي هڪ سال اڳ کان وڌيڪ هئي. آپريٽر ڊولپمينٽ کي ڇڏي ڏنو ويو آهي: Kubernetes جو تازو ورزن ٻڌايو ويو آهي جيئن ته سپورٽ ڪئي وئي آهي 1.9.

4. Cassandra-آپريٽر طرفان Rook

• GitHub
• تياري: الفا
• لائسنس: Apache 2.0
• ۾ لاڳو ٿيل: گولانگ

هڪ آپريٽر جنهن جي ترقي ترقي نه ٿي رهي آهي جيترو جلدي اسان چاهيون ٿا. ان ۾ ڪلستر مينيجمينٽ لاءِ چڱي طرح سوچيل CRD ڍانچو آهي، ڪلسٽر آءِ پي سان سروس استعمال ڪندي نوڊس جي سڃاڻپ جو مسئلو حل ڪري ٿو (ساڳي ”هيڪ“)... پر اهو سڀ ڪجهه هاڻي لاءِ آهي. في الحال ڪوبه مانيٽرنگ يا بيڪ اپ نه آهي دٻي مان (رستي سان، اسان مانيٽرنگ لاءِ آهيون پاڻ ورتو). هڪ دلچسپ نقطو اهو آهي ته توهان هن آپريٽر کي استعمال ڪندي ScyllaDB پڻ ترتيب ڏئي سگهو ٿا.

NB: اسان هن آپريٽر کي اسان جي منصوبن مان هڪ ۾ معمولي ترميمن سان استعمال ڪيو. آپريشن جي پوري عرصي دوران آپريٽر جي ڪم ۾ ڪو به مسئلو محسوس نه ڪيو ويو (4 مھينن جي آپريشن).

5. نارنگي مان CassKop

• GitHub
• تياري: الفا
• لائسنس: Apache 2.0
• ۾ لاڳو ٿيل: گولانگ

لسٽ تي سڀ کان ننڍو آپريٽر: پهريون ڪم 23 مئي 2019 تي ڪيو ويو. اڳ ۾ ئي هاڻي ان جي هٿيارن ۾ اسان جي فهرست مان خاصيتون جو هڪ وڏو تعداد آهي، جنهن جا وڌيڪ تفصيل پروجيڪٽ جي مخزن ۾ ملي ڪري سگهجي ٿو. آپريٽر جي بنياد تي ٺهيل آهي مشهور آپريٽر-sdk. باڪس مان ٻاهر جي نگراني کي سپورٽ ڪري ٿو. ٻين آپريٽرز کان بنيادي فرق استعمال آهي CassKop پلگ ان، پٿون ۾ لاڳو ڪيو ويو ۽ Cassandra نوڊس جي وچ ۾ رابطي لاءِ استعمال ڪيو ويو.

پهچڻ

ڪئاسندرا کي ڪبرنيٽس تائين پهچائڻ لاء طريقن ۽ ممڪن اختيارن جو تعداد پاڻ لاء ڳالهائيندو آهي: موضوع طلب ۾ آهي.

هن اسٽيج تي، توهان مٿين مان ڪنهن به ڪوشش ڪري سگهو ٿا پنهنجي خطري ۽ خطري تي: ڊولپرز مان ڪو به ضمانت نه ٿو ڏئي 100٪ پيداوار جي ماحول ۾ انهن جي حل جي آپريشن. پر اڳ ۾ ئي، ڪيتريون ئي پراڊڪٽس ترقي جي بينچ ۾ استعمال ڪرڻ جي ڪوشش ڪرڻ لاء واعدو نظر اچن ٿا.

منهنجو خيال آهي ته مستقبل ۾ اها عورت ٻيڙيءَ تي ڪم ايندي!

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

• «ڪوبرنيٽس ڏانهن MongoDB جي بي ترتيب لڏپلاڻ"؛
• «ڪبرنيٽس ڏانهن RabbitMQ جي بيحد لڏپلاڻ"؛
• «ڊيٽابيس ۽ ڪبرنيٽس (جائزو ۽ وڊيو رپورٽ)"؛
• «K8s ٽوٽڪا ۽ ترڪيبون: وڏي ڊيٽابيس لاءِ بوٽ اسٽريپ کي تيز ڪرڻ».

جو ذريعو: www.habr.com