403

Description
No man should escape our universities without knowing how little he knows.
- Robert Oppenheimer
Contact: @AmirMohGh
We recommend to visit

?? ??? ?? ????? ?

We comply with Telegram's guidelines:

- No financial advice or scams
- Ethical and legal content only
- Respectful community

Join us for market updates, airdrops, and crypto education!

Last updated 1 year, 9 months ago

[ We are not the first, we try to be the best ]

Last updated 1 year, 11 months ago

FAST MTPROTO PROXIES FOR TELEGRAM

ads : @IR_proxi_sale

Last updated 1 year, 7 months ago

1 year, 5 months ago
1 year, 5 months ago

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

1 year, 5 months ago
1 year, 5 months ago

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

1 year, 7 months ago

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

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

1 year, 7 months ago

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

1 year, 7 months ago
سلام

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

3 years, 7 months ago

شاید اسم 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/

3 years, 7 months ago

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

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

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

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

3 years, 7 months ago

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

We recommend to visit

?? ??? ?? ????? ?

We comply with Telegram's guidelines:

- No financial advice or scams
- Ethical and legal content only
- Respectful community

Join us for market updates, airdrops, and crypto education!

Last updated 1 year, 9 months ago

[ We are not the first, we try to be the best ]

Last updated 1 year, 11 months ago

FAST MTPROTO PROXIES FOR TELEGRAM

ads : @IR_proxi_sale

Last updated 1 year, 7 months ago