سلام
با یه بنده خدایی بحثم شد ایشون رو که نتونستم قانع کنم فعلا ولی دوست دارم حداقل افراد عاقلی که این پستو میخونن رو قانع کنم.
خیلی دوست دارم از کلاسترینگ بگم یا بهتره بگم سرویس توزیع شده کلاستری. شاید اولش خیلی تئوری بنظر بیاد ولی اگر حوصله کنم بنویسم سر ۲ هفته بدجور عملی میشه. توی مبحث سیستم های توزیع شده ما موضوعی به اسم Consensus داریم. همونطور که اسمش میگه الگوریتم های تجمیع زیرساخت هر سرویس کلاستری ای هستن و مثالشون رو جلوتر میزنم روز به روز ازشون استفاده میکنیم و خبر نداریم. در اصل اتفاقی که میفته چند تا Node با هم به نتیجه میرسن که حالت فعلی چیه و چکار باید بکنن.

مرسوم ترین این الگوریتم ها Paxos ( که زوکیپر نسخه مشابه به این رو برای خودش طراحی کرده استفاده میکنه و چندین اپلیکیشن معروف دیگه) و Raft ( که Etcd استفاده میکنه ازش و Corosync ( که بعدا راجع بهش مینویسم)). Paxos الگوریتم نسبتا پیچیده ایه و موقعی که Raft رو رونمایی کردن عملا گفتن که الگوریتم ساده تر و قابل فهم تر از Paxos رو مطرح کردن. مقداری Raft رو توضیح میدم تا بعدا که چیزای جالب تر بنویسم.

ساده ترین حالتی که بخوام رفت رو توضیح بدم اینطور هست که ابتدا تعدادی نود (معمولا تعداد فرد که دلیلش رو میگم بزودی) کانفیگ میشن که از این الگوریتم استفاده کنن. هرکدوم از این نود ها یه تایمری داره که بعد از تموم شدنش به همه Heartbeat میفرسته و ازشون فیدبک میگیره و تایمر رو ریست میکنه (چیزی که میگن این هست که این تایمر رو حدودا مشابه با RTT بزارید) طبق الگوریتم Leader Election (انتخاب رهبر) اولین نودی که متوجه نبود لیدر میشه به همه نود ها تقاضای لیدر شدن میفرسته و بعد از گرفتن پاسخ تبدیل به لیدر میشه. فرض کنیم میخوایم مقداری رو در تمامی نود ها اضافه کنیم. این تغییر رو به نود لیدر میفرستیم تا اعمال کنه- بعد لیدر به همه نود ها این تغییر رو ارسال میکنه و پیامی ازشون دریافت میکنه که متوجه بشه تغییرات در همه نود ها اعمال شدن.

یه نکته ای که وجود داره این هست که کلاستر ما تا وقتی کار میکنه بیشتر از نصف (Quorum) نود فعال باشن. یعنی وقتی از ۵ نود ۲ نود زنده باشن کلاستر ما متوقف میشه. دلیلش چیه؟
فرض کنیم اینطوری نبود و درصورتی که از ۵ نود ۲ نود زنده بودن کلاستر کار میکرد. تو همین حالت تصور کنید همه ۵ نود زنده هستن و بطور ناگهانی بین نود ها پارتیشنی صورت میگیره و از سمت نتوورکی ۳ نود از ۲ نود جدا میشن. الان ۳ نود ما فکر میکنه همه چی رواله و به کارش ادامه میده بطور همزمان ۲ نود هم فکر میکنن همه چی رواله و به کارشون ادامه میدن. اتفاقی که افتاد این هست که ما الان ۲ تا لیدر داریم که تغییرات رو اعمال میکنن!!!!!! به این حالت Split-Brain میگن. چون نصف دیتای ما با نصف دیگه فرق داره و مغز جدایی دارن! پس برای جلوگیری از این مشکل این شرط رو گذاشتن که فقط و فقط درصورت وجود quorum تغییرات "کامیت" بشن. در این صورت اگر پارتیشن پیش بیاد پارتیشن ۲ نودیمون تغییرات رو اعمال نمیکنه چون چیزی که میبینه این هست که نصف کمتر نود ها فعالن- بطور همزمان سمت پارتیشن ۳ نودمون همه تغییرات اعمال میشه و بعد از حل پارتیشن که ۲ نود به ۳ نود می پیوندن دیتا "synchronize" میشه.

سوالات:
اولین سوال: RTT چیست؟ زمانی که طول میکشه رکوئست شما به نود دیگه برسه و نتیجش برگرده.
سوال بعدی: چرا تعداد نودارو زوج نذاریم؟ فرض کنید ۸ نود داشته باشیم. نصف این نود ها میشن ۴- طبق چیزی که بررسی کردیم Fault Tolerance ما با ۸ نود میشه ۳ (‌همواره باید بیشتر از نصف نود های زنده باشن که میشه ۵ نود- هشت منهای پنج هم میشه ۳). اگر ۷ نود هم داشته باشیم باز تا ۳ نود FT داریم. پس عملا نود اضافی گذاشتیم که نه تنها کمکی نمیکنه- بلکه یه نقطه خرابی و دردسر دیگست.
سوال بعدی: FT چیه؟ Fault Tolerance یعنی تعداد نود هایی که میتونیم از دست بدیم و سرویس زنده بمونه. معمولا این عدد n/2-1 هست.
اینایی که گفتم مسخره بازی یا تئوری نیستا! کوبرنتیزی که همه "عاشقش" هستیم از Etcd استفاده میکنه که اونم از Raft استفاده میکنه.
تعدادی نتیجه گوگل سرچ جالب:
1. Some deployment tools set up Raft consensus algorithm to do leader election of Kubernetes services.
2. Zab (ZooKeeper Atomic Broadcast) is the Paxos- variant consensus protocol that powers the core of ZooKeeper, a popular open-source Paxos system.
3. http://thesecretlivesofdata.com/raft/#home
4. https://en.wikipedia.org/wiki/Paxos_(computer_science)

شبیه ساز الگوریتم Raft:
https://raft.github.io/

کامنت اضافه شد.

سلام دوباره
۲ تا تغییر سیاست کوتاه بگم بعد میریم سر اصل مطلب:
۱. میخوام تعداد پستارو بیشتر کنم (۲-۳ روز یبار) ولی کوتاه تر
۲. پست ها انسجامی ندارن ولی طولانی مدت (۱-۲ ماه) یدفعه میبینید مجموعه ای از اطلاعات کم ارزش بهم ربط پیدا میکنن و ارزشمند میشن.

خب‌ مقدار کمی از Replication میگم.
یکی از اهداف در سیستم های توزیع شده High Availability (HA) هست. یعنی من سرویسم طوری باشه که وقتی تعدادی از نود ها یا بخشی از سرورهام پایین میرن سرویسم ادامه بده. برای سرویس هایی که دیتا نگه میدارن لازمه این اتفاق این هست که دیتا بین همشون Replicate بشه. یعنی به اصطلاح یه کپی از دیتا رو هر نودی داشته باشه که بتونه به ملت نمایش بده (تعریف بسیار سطحی). اگر تلاش کنیم رپلیکیشن رو تصور کنیم به ۲ ساختار کلی میرسیم (به فرض وجود ۳ نود):
۱. بعد از گرفتن دستور Write، اول روی نودی که دستور رو دریافت کرده Write انجام بشه، سپس به یوزری که درخواست داده پیام تایید داده بشه. بعد به همه نود های دیگه فرستاده بشه.
۲. بعد از گرفتن دستور Write، نودی که دستور رو دریافت کرده به بقیه نودها تغییرات رو ارسال میکنه و بعد از اینکه همه تایید کردن که تغییرات انجام شد به یوزر پیام تایید فرستاده بشه.

فرق این دوتا چیه؟ توی حالت اول فرض کنید درخواست Write اومد و دیتا تغییر پیدا کرد (و به یوزر Success ارسال شد) ولی بلافاصله سرور کرش کرد و خاموش شد. حالا درخواست های بعدی به سرور های دیگه میره درحالی که سرور اولی فرصت نکرده تغییرات رو به اینا بفرسته و دیتای سرورای دیگه قدیمی هست. پس عملا ما در این حالت دیتای اشتباه نشون دادیم.
در حالت دوم اگر همین اتفاق بیفته (بعد از گرفتن درخواست از یوزر شروع به اعمال تغییرات در همه سرور ها کنیم) و سرور خاموش بشه میدونیم که همه سرور ها دقیقا و دقیقا دیتا مشابه دارن و اصطلاحا Consistency داریم. حالت اول رو Asynchronous و حالت دوم رو Synchronous میگن.
در Asynchronous Replication یوزر با سرعت بیشتری نتیجه رو میگیره (چون لازم نیست منتظر رپلیکیت شدن دیتا بین همه سرورها باشه) ولی Consistency کمتری داره‌ (یعنی ممکنه بعد از کرش شدن یک سرور و رفتن درخواست ها روی سرور جدید (Fail-Over) دیتا عقب جلو بشه).
حالت دوم کند تره و نتیجه رکوئست دیرتر میرسه منتهی میدونیم همه سرور ها دیتای کاملا مشابه دارن، درصورت داشتن دیتا حساس بلا استثنا از این نوع رپلیکیشن استفاده میشه.

منبع هم لازم نیست چون بسیار مطلب این سری سبک بود. احتمالا خیلیا اینارو میدونستن. ولی بیانش لازم بود.

شاید اسم Etcd رو خیلی دیده باشید ( مخصوصا کسایی که کوبرنتیز کار کردن). ما نوعی دیتابیس داریم به نام Key-Value Store، توضیح نمیدم چون خیلی کلیدی (😁) هست و اکثرا میدونید. اتسیدی (یا ای تی سی دی) ویژگی هایی داره که نسبت به KV Store های دیگه متمایزش میکنه:
۱. توزیع پذیر بودنش
۲. Consistency
۳. و اینکه تغییرات رو مانیتور میکنه و به روش های مختلف تحویل میده

کاربرد زیادی داره در میکروسرویس ها.
فرض کنید شما اپلیکیشنی دارید که متشکل از ۲۰ تا میکروسرویسه (به بخش های کوچکتری تقسیم شده که هرکدوم بخشی از کار رو هندل میکنن، همین تلگرام هم برای بخش های مختلفش میکروسرویس های جدا داره (مثل مدیریت بات ها، مدیریت پیام ها، ارسال نوتیف، وویس چت و ...)) در این صورت نمیتونید به اصطلاح آدرس های این هارو برای هم Hardcode کنید و باید حالت دینامیک وجود داشته باشه. که مثلا اگر من تصمیم گرفتم یک میکروسرویس رو روی سرور جدیدی بالا بیارم یا ازش ۳ تا بالا بیارم نیازی به ایجاد تغییر در کد یا کانفیگ تمامی میکروسرویس ها نداشته باشم.
معماری جایگزین این هم وجود داره. هر میکروسرویس آدرس خودش رو در اتسیدی میریزه و سرویس هایی که میخوان ارتباط بگیرن میان از اتسیدی آدرس سرویس رو برمیدارن به عنوان مثال:
سرویس کنترل وویس با آدرس 192.168.11.222 میاد و این دیتارو وارد KV Store میکنه:
service.voice 192.168.11.222
سرویس که بخواد آدرس رو برداره از فانکشن گت استفاده میکنه و آدرس رو پیدا میکنه. به این نحوه استفاده از Etcd میگن Service Discovery (کشف سرویس ها).
شاید باید براتون سوال شده باشه، سرویسی که (به فرض کرش) میره پایین چجوری وقت میکنه آدرسشو از استور حذف کنه؟؟؟
قابلیت دیگه ای که در اتسیدی وجود داره به نام Lease. خیلی کلی توضیح بدم، میاد و تایمری رو شروع میکنه (از عدد دلخواه) و شما کلید و مقدار رو تحت اون Lease ایجاد میکنید و وقتی که مهلت "اجاره" تموم بشه اون کلید و مقدار رو میریزه دور که اگر سرویسی درخواست دیدن مقدار رو داشت خطا بگیره. این تایمر بالاخره تموم میشه پس قبل از تموم شدنش باید میکروسرویس بیاد و Refresh انجام بده. یعنی بگه من زندم و تا (مثلا) ۶۰ ثانیه آینده من رو تمدید کن و اینکار از سمت کد توسط برنامه نویس انجام میشه. صرفا از جنبه سرویس دیسکاوری نگاه کردیم، خیلی موارد هم نادیده گرفته شد برای کوتاه کردن پست. شبتونم بخیر
1. https://etcd.io/docs/v3.3/learning/why/
2. https://etcd.io/docs/v3.5/tutorials/how-to-create-lease/

سلام
در باره بعضی دیتابیس هایی که تو Distributed Systems مطرح هستن تحقیق میکردم، که به این سایت برخوردم:
https://jepsen.io/analyses
اینا یه فریموورکی ساختن (با 7 هزار ستاره!!) کلا کارشونم این هست که یه سری محصولات رو بررسی میکنن و میگن که آیا با مستنداتشون و ادعاهاشون مطابقت داره یا نه.
دیتابیس های زیادی رو پوشش دادن، بنظرم اگر با هرکدوم از اینا در مقیاس بالا کار میکنید ارزش داره مقاله مرتبطشو یه بررسی جزئی بکنید.
#Databases

چرا کوبرنتیز از Etcd استفاده میکنه؟
✍️ تازگیا برام این سوال ایجاد شد و راجع به این موضوع یک سری تحقیقات انجام دادم، نتایج رو در قالب چند پست تو کانال قراره بگذارم:
1. تا چه حد این جمله درسته؟ آیا واقعا فقط از Etcd استفاده میشه؟
2. (دقیقا) چرا از دیتابیس های SQL استفاده نکردن؟
3. (دقیقا) چرا از دیتابیس های KV دیگه استفاده نکردن؟
#Kubernetes #Etcd

چرا کوبرنتیز از Etcd استفاده میکنه:
آیا واقعا فقط از Etcd استفاده میشه؟ (بخش اول: Kubernetes Distributions)
✍️ نصب و بالا آوردن یک کلاستر کوبر چندتا مشکل داره:
1. منابع مورد نیاز
2. پیچیدگی نصب
برای همین تعداد زیادی سولوشن برای حل این دو مشکل به وجود اومدن، دسته ای از این سولوشنا فرایند نصب رو ساده تر میکنن (مثل KubeADM KinD Kubespray) ولی بعضیاشون کلا باینری هایی که مدیریت کلاستر رو به عهده دارن رو تغییر دادن و برای نصبش هم یک اسکریپت گذاشتن (مثل K3S و K0S).

دسته دوم تحت واژه توزیع های کوبرنتیز (Kubernetes Distributions) شناخته شدن و هر کدوم کاربرد خاصی دارن (مثلا سبک هستن و برای IoT و HomeLab میشه ازشون استفاده کرد یا ابزار خاصی کنارشون نصب میشه و داشبورد مدیریتی آماده دارن و ...).
#K3S #K0S #KubeADM #Kubespray #KinD

سلام.
با سید مهدی (@seyedmahdidiary) میخوایم پادکست بزاریم، بخش آخر پادکست سوالاتی که کامنت میکنید رو (تا حد توان و سوادمون) جواب میدیم.
بصورت کلی هر سوالی که مربوط به Devops SRE Linux و یا Python میشه رو میتونید بپرسید.

میدونستید اگه دیسک یه کامپیوتر/سرور رو ازش جدا کنید، بازم میتونید دیتاشو بخونید؟
بطور کلی سیستم عامل برای نشون دادن هر فایل، باید اول اون رو توی رم بریزه.
حالا هر فایلی که خونده میشه با توجه به یه سری پارامتر قابل کنترل، میتونه بعد از اینکه خونده شد توی رم بمونه تا سری بعد مجددا از دیسک فراخوانی نشه، چون IO بصورت کلی خیلی هزینه و زمان بره.
اگر میخواید تاثیر این cache رو ببینید میتونید از کامند زیر یک بار با کش و یک بار بی کش استفاده کنید:

Without caching:
dd if=/dev/zero of=/tmp/file bs=1M count=1000 oflag=direct
With caching:
dd if=/dev/zero of=/tmp/file bs=1M count=1000

و چون این دیتا تو رم وجود داره، حتی اگر دیسک هم جدا بشه سیستم عامل اون درایو رو به حالت Read-only تغییر میده و به شما اجازه میده هرچی تو کش سیستم عامل هست رو بخونید.
روش تست کردن این موضوع هم به این شیوه هست کامند زیر رو بزنید:

free -h
Sample output:
total used free shared buff/cache available
3.8Gi 485Mi 937Mi 24Mi 2.4Gi 3.0Gi

که میزان کش فعلی رو در قسمت buff/cache نشون میده ولی وقتی کامند زیر رو بزنید کش ها پاک میشن و دیسکی که از سیستم جدا شده دیگه قابل Read هم نیست:

echo 3 | sudo tee /proc/sys/vm/drop_caches

#Tips #Funfact #Linux #OS #Filesystem

اگه براتون سواله که از چه دیتابیسی استفاده کنید، میتونید به لینک زیر مراجعه کنید😁.
https://choosedb.com/

شاید تو خیلی از بازرسی ها امنیتی دیده باشید به ورژن اپلیکیشن گیر میدن، و عموما هم بدون توجه به این خطا ها رد میشیم. ولی چرا از نظر امنیتی مشکل داره که ورژن پکیج/سرویس/اپلیکیشن ها قدیمی باشه؟

1. آشنایی با CVEsها: اول با مبحث CVE آشناتون میکنم، هر باگ امنیتی ای که توسط Community یا صاحب اپلیکیشن پیدا میشه، به اون اپلیکیشن/سرویس گزارش میشه و طی بازه زمانی کوتاهی Patch میشه (اگر دلشون بخواد!) و نسخه جدیدی رو بیرون میدن. بعد یا قبل از اینکه پچ رو بدن براش یک CVE ثبت میکنن تا همه درجریان این مشکل قرار بگیرن و آپگرید کنن.

2. همیشه Scanner ها مشغول به کارن: تعداد آی پی های اینترنت خیلی کمه ( تقریبا 4 میلیارد)، به همین دلیل یک نفر میتونه یک پورت خاصی رو تو بازه زمانی خیلی کوتاه (مثلا چند ساعت) در بستر کل اینترنت Scan کنه. بعد از اینکه اسکن کرد نتایج رو فیلتر میکنه و ورژن مدنظرشو طبق لیست CVE ها پیدا میکنه و یه اپلیکیشن/سازمان رو میاره پایین.

3. پسوورد امن سرور و سرویس: بعضی از این اسکنر ها هم همیشه مشغول Brute Force کردن سرور ها هستن، اگر به لاگ SSHD سرورتون مراجعه کنید:

journalctl -u ssh -f

احتمالا چندین لاگین ناموفق میبینید. معمولا هم از لیست پسوورد های معروف استفاده میکنن پس قبل از اینکه پسوورد بزارید چک کنید تو این لیست نباشه. (مثال از Password List)

4. حمله های Zero-Day: وقتی یک آسیب پذیری (CVE) جدید میاد، همه شروع میکنن به اسکن کردن اینترنت برای پیدا کردن اون نسخه خاص از سرویس مدنظر. این باعث میشه اگر تو 1-2 روز اول آپگرید نکنید قطعا مورد حمله قرار بگیرید.

5. سرور شما همیشه مورد حمله قرار داره: با توجه به راحتی اسکن کردن و تعداد بالای افرادی که از این کار لذت میبرن، میتونید فرض رو بر این بزارید که در هر لحظه سرور های Edge شما مورد حمله قرار دارن و هر آسیب پذیری داشته باشن بلافاصله پیدا و سو استفاده میشه.
با یک مثال این پست رو تموم میکنم، فرض کنید همین امروز یک آسیب پذیری بیاد که بشه به هر سروری که ورژن SSH Serverش OpenSSH_9.7p1 هست بدون نیاز به پسوورد لاگین کنیم. و از قضا ماهم رو همین ورژنیم، چیزی حدود 1 ساعت بعد از گزارش باگ اگر هنوز از اون ورژن استفاده میکنید میتونید با سرور خدافظی کنید 😁.
#Security #OS

مدیریت لاگ در Docker:
تاحالا مسیر زیر رو دیدید؟

/var/lib/docker/containers

توی این مسیر به ازای هر کانتینر یک دیرکتوری وجود داره که توش یه سری فایل هست ولی تمرکز من تو این پست روی فایل زیر هست:

container-id-json.log

*اسم فایل به آی دی کانتینر بستگی داره

اگر کانتینرتون لاگ زیادی تولید میکنه، ممکنه باعث پر شدن دیسک و در نتیجه خطا گرفتن از سرویسا بشه.
راه محدود کردن این لاگ به 3 شیوه زیره:
موقع ساخت کانتینر:

docker run -d --log-driver json-file --log-opt max-size=10m --log-opt max-file=3 nginx:alpine

داکرکامپوز:

version: "3.8"
services:
nginx:
image: nginx:alpine
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"

تغییر تنظیمات Docker Daemon در مسیر etc/docker/daemon.json/:

{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}

لیست پارامتر ها و کاربردشون رو میتونید تو مستندات داکر مطالعه کنید.
#Docker

این سایت کار با Git بصورت Interactive یاد میده و نقطه شروع خیلی خوبیه:
https://learngitbranching.js.org/
#Git

سلام
(احتمالا) همه اسم Redis رو شنیدیم. دیتابیس از نوع Key-Value هست که کاری ندارم و میتونید جزئیاتش رو مطالعه کنید.
یه نکته ای که هست، ردیس بطور کلی دیتارو تو رم نگهداری میکنه و این یعنی وقتی ریستارت بشه تمامی دیتا از بین میره چون همش روی مموری ذخیره شده.
خیلی وقتا (به طرز عجیبی) نیازه که دیتایی که ذخیره میکنیم پاک نشه و بمونه، اون موقع ردیس 2 تا راهکار ارائه میکنه:

1. AOF:
تو این حالت ردیس بصورت مستقیم تمامی دستورات Write رو (همینطور که تو رم داره) روی دیسک ذخیره میکنه که اگر به هر دلیلی پروسه ردیس متوقف شد و مجددا شروع به کار کرد میتونه اون فایل رو از بالا به پایین بخونه و دیتارو دوباره بریزه تو رم. اینکه بلافاصله بعد از هر عملیات بریزه تو فایل یا هر n ثانیه بریزه تو فایل، بستگی به کانفیگ Redisتون داره. مناسب برای وقتی که داده حساسه و حتی 1 کلید هم ارزشمنده، مثلا وقتی پیام کاربرا (تو یه پیامرسان) رو موقتا تو ردیس ذخیره میکنید.
2. RDB:
این مکانیزم در بازه های زمانی قابل تغییری، از کل دیتا Snapshot میگیره و در صورت بروز خطا براتون دیتارو از آخرین اسنپشات برمیگردونه. فایل Snapshot از فایل هایی که توسط AOF ایجاد میشن حجم کمتری دارن و نگهداریشون راحت تره، همچنین شروع دوباره ردیس با اسنپشات سریعتره از حالتی که باید AOF رو لود کنه. مناسب برای وقتی که داده حساسیت کمتری داره و تا چند دقیقه Data Loss قابل قبوله. مثلا نگهداری سشن کاربرا.

نتیجه: اگر دنبال Persistence بصورت قطعی هستید، که مطمئن باشید درصورت ریستارت شدن ردیس دیتا برمیگرده، باید از AOF استفاده کنید. در غیر این صورت RDB Snapshot گزینه کم مصرف تریه. اینکه دقیقا کدوم بدرد کارتون میخوره تو این لینک میتونید مطالعه کنید.
نکته: میشه از هردو گزینه بصورت همزمان استفاده کرد، که هم دیتا با اطمینان بالا نگهداری بشه، هم موقع بالا اومدن (با استفاده از RDB) ردیس سریعتر روشن بشه.


خیلی دوست دارم تو پست های بعد راجع به گزینه های رسیدن به High Availability تو ردیس بگم.
سایر رفرنس ها:
1. How Redis Stores Data: Exploring RDB, AOF, Hybrid, and No Persistence
2. Understanding Persistence in Redis — AOF & RDB + on Docker
3. BGREWRITEAOF

#Redis

یه ایرادی که خیلی بین تازه کار ها رایجه، متمایز نبودن کلمات Encoding ،Encryption و Hashing تو ذهنشونه.
حتی تو افراد باتجربه هم دیدم که بصورت فعال اینارو متمایز نمیبینن.
سعی میکنم خیلی ساده توضیح بدم چون در پست های بعد حتما ازشون استفاده میشه.

1️⃣ ‏Encoding: در واقع یک رشته (مجموعه ای از کاراکتر ها) تبدیل به رشته جدیدی کنیم، بصورتی که صرفا با دونستن الگوریتم Encoding استفاده شده بشه بازگردانیش کرد.
یکی از Encodingهای معروف Base64 هست که نحوه کارکردشو میتونید تو GPT ببینید.

‏2️⃣ Encryption: وقتی یه متن رو Encrypt میکنیم، که با استفاده از یک کلید انجام میشه حتما باید اون کلید رو (تو رمزنگاری متقارن) داشته باشیم تا بتونیم به عبارت اولیه برسیم. (مثل AES)

پس وقتی میگیم Encoding، فقط با دونستن الگوریتم میتونیم عبارت اولیه رو پیدا کنیم (و اصطلاحا Decode کنیم).
ولی وقتی میگیم Encryption یعنی هم باید الگوریتم رو بدونیم، هم کلیدو داشته باشیم.

3️⃣ ‏Hashing: وقتی یه عبارت Hash میشه، دیگه به هیچ عنوان بازگردانی نمیشه. (مثل SHA256)
2 تا دلیل برای اینکه بازگردانی نمیشه هست:
1. توابع Hashing یک به یک نیستن.
2. معکوس ناپذیر هستن.
این 2 تا باهم این معنی رو میدن که اولا برگشتن مسیر الگوریتم یه تابع Hash اینقدری پیچیده هست که پیش بینی نمیشه هیچ پردازنده ای بتونه مسیر رو برگرده. دوما اگر هم برگرده، یک عبارت Hashشده بیشتر از 1 جواب برمیگردونه
یعنی اگر مسیر تابع رو برگردیم، به بی نهایت عبارت اولیه میرسیم.

کلا Hashing خیلی پرکاربرده و دوست دارم یه پست از کاربرداش هم بزارم.

#Cryptography

گاهی اوقات بیشتر از یک پروسه بکند داریم که ممکنه روی سرور های مختلفی باشن و میخوایم درخواست ها به همه اینا برسه. تو اینطور شرایط از چیزی به اسم LoadBalancer استفاده میکنیم.
کارش اینه که روی یک پورت لیسن میکنه و هرچی درخواست میاد رو میفرسته به آدرس یا آدرس هایی که بهش میگیم.
نمونه: Haproxy و Nginx (چند ده محصول معروف دیگه هستن که اسمشون رو نمیگم)
سوالی که پیش میاد اینه که چطور میفهمه به کدوم بکند بفرسته؟

الگوریتم های LoadBalancing:
1️⃣ ‏Round Robin: الگوریتم خیلی معروف در Scheduling هست که بصورت ترتیبی درخواست هارو به ترتیب به بکند های مختلف ارسال میکنه.

2️⃣ ‏Least Connections: بررسی میکنه که درحال حاضر چند کانکشن به هر سرور بازه، و درخواستو میفرسته به اونی که درحال حاضر کمترین تعداد کانکشن رو داره.

3️⃣ ‏Source IP Hash: هر درخواستی که میاد رو بررسی میکنه، آدرس IP و Port مبدا و مقصد رو تو یه جدول نگهداری میکنه و همیشه درخواست های یک Source IP خاص رو به یک بکند خاص میفرسته.

اینا پرکاربردترین الگوریتم ها هستن و هرکدوم تو شرایط خاص خودشون کاربرد دارن. اگر علاقه مند هستین میتونید از ChatGPT الگوریتمای بیشتری رو پیدا کنید.

وارد جزئیات نمیشم ولی مثلا وقتی Websocket استفاده میکنیم بطور معمول نیاز میشه که از Source IP Hash استفاده کنیم (اگر میخواید تو ChatGPT سرچ کنید، به این برمیگرده که وبسوکت از نوع Stateful Connection هست).

#LoadBalancing

bind: Address already in use
این ارور یه دروغه
میدونستین 2 تا Process میتونن همزمان روی یک پورت Listen کنن؟
توی TCP یه فلگی هست که اجازه میده پروسه بعدی که میخواد روی یه پورت لیسن کنه بتونه همزمان اینکارو انجام بده و این فلگ SO_REUSEPORT هست.
وقتی از این فلگ استفاده میکنیم کرنل خودش بین این 2 تا پروسه فرایند LoadBalancing انجام میده.

اینکه با چه الگوریتمی لودبلنس میکنه
و یا از چه ورژن کرنل به بعد قابل دسترس هست رو میتونین از ChatGPT پیدا کنین.

#OS #Network #Funfact