https://virgool.io/feed/@nmgolbaz2012 علاقه‌مند به برنامه‌نویسی؛ زیرساخت و تکنولوژی fa 2026-06-17 04:59:49 https://files.virgool.io/upload/users/1064301/avatar/sPKYci.jpeg?height=120&width=120 https://virgool.io/@nmgolbaz2012 https://virgool.io/@nmgolbaz2012/%D9%86%DA%AF%D8%A7%D9%87-%D8%A7%D8%AC%D9%85%D8%A7%D9%84%DB%8C-%D8%A8%D9%87-iptables-%D8%A8%D9%87-%D8%B5%D9%88%D8%B1%D8%AA-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%DB%8C-scfci1psoxi1 وقتی هنگام استفاده از توزیع های لینوکس اسم از فایروال میاد همیشه اولین مواردی که به ذهن همه میرسه ufw(debian base) و firewalld(RedHat base) هست. این دو interface ها یا رابط‌هایی برای کاربر هستن که اجازه بررسی و مدیریت شبکه رو به کاربر میدن. میدونیم که توی توزیع‌های مختلف لینوکس کرنل‌ها یکی هستن و فایروال اصلی که مستقیم با کرنل در ارتباط هست IPTABLES هست و موارد بالا فقط یک رابط برای آسان‌تر شدن درک دستورات و به نوعی user friendly بودن اون به وجود اومدن. حقیقت اینه که اگر نیازهای ما یک مقدار از موارد پایه و basic جلوتر بره ناچار به استفاده از iptables هستیم و یکم جلوتر باهم میبینیم که اتفاقا بعد از فهمیدنش خیلی راحت به مواردی که نیاز داریم میرسیم. توی این مجموعه مطلب قصد داریم به‌صورت کاربردی با iptables آشنا بشیم و همزمان با درک مفاهیم از اونها استفاده کنیم.- اولین موردی که ما معمولا از یک فایروال انتظار داریم بستن یک پورت روی سرور؛ یا باز گذاشتن اون برای تعداد محدودی IP هست.اگه خیلی ساده بخوایم نگاه کنیم؛ iptables یک سری جدول از قوانین داره که توی موقعیت‌های مختلف میاد و اونها رو بررسی میکنه؛ مثلا وقتی یه packet به interface شبکه ما میرسه(INPUT)؛ iptables میره و جدول قانون هایی که برای ورود به شبکه تعریف شده رو بررسی میکنه یا مثلا وقتی یه packet قراره از شبکه ما خارج بشه میره و قوانین که توی جدول خروجی (OUTPUT) وضع شده رو بررسی میکنه و اگه همه اونها رعایت شده بود اجازه خروج رو به packet مورد نظر میده.چطور قوانین دلخواهمون رو وضع کنیم؟برای وضع یک قانون مشخصا یک سری متغیر داریم که بسته به شرایط و جدولی که مدنظرمون هست فرق میکنن. اینجا ما قصد ایجاد rule برای پکت های ورودی رو داریم پس باید چندتا مورد رو بررسی کنیم:آدرس مبدا یا مقصد: مثلا میخوایم مشخص کنیم اگه packet یا درخواست از یک ip مشخص بود قبول بشه و غیر از اون رد بشه.پورت مقصد یا مبدا: خیلی برای ما مهم هست درخواست با کدوم پورت کار داره. مثلا اگه ما یک mysql server داشته باشیم به هیچ وجه نباید پورت اون برای همه باز باشه و اینجا باید هرکسی با پورت ۳۳۰۶ کار داشت رو رد کنیم!پروتکلی که packet داره ازش استفاده میکنه. دستورالعمل برای پکتی که شرایط مدنظر مارو داره؛ مثل ACCEPT کردن یا DROP کردنو مورد آخر جایگاه قانون توی جدول هست؛ iptables قوانین رو به ترتیب از بالا شروع میکنه به چک کردن و مثلا اگه پکت ورودی با شرایط قانون اول ما همخوانی داشت و دستور ACCEPT رو بهش داده بودیم دیگه نمیره قانون بعدی رو چک کنه و درخواست قبول میشه. مثلا قوانین زیر رو بررسی کنیم باهم:-هر درخواستی برای پورت ۴۴۳ اومد رو DROP کن.-اگه درخواستی برای پورت ۴۴۳ اومد و آدرس مبدا اون x.x.x.x بود رو ACCEPT کن.توی این موقعیت هیچ درخواستی برای پورت ۴۴۳ قبول نمیشه چون اول قانون اول بررسی میشه و همونجا همشون DROP میشن و عملا کار به دستور بعدی نمیرسه. برای همین همیشه اول مواردی که نیاز داریم رو ACCEPT میکنیم و بعد از همه مواردی که نیاز نداریم رو DROP میکنیم.حالا میخوایم باهم دیگه مثلا پورت ۴۴۳ رو فقط برای آیپی ۱۰.۱۰.۱۰.۱۰ باز بذاریم و هر درخواستی از این آدرس اومد رو قبول کنیم:طبق چیزی که گفتیم اول میایم و درخواست هایی که قراره ACCEPT بشن رو قبول میکنیم:iptables -I INPUT 1 -p tcp -s 10.10.10.10 --dport 443 -j ACCEPTiptables -I (جدول مورد نظر و جایگاه قانون) -p (پروتکل) -s (آدرس مبدا) --dport(پورت مقصد در پکت) -j (دستورالعمل)بعد از اون میایم و هر پکتی که با پورت ۴۴۳ کار داشت رو رد میکنیمiptables -I INPUT 2 -p tcp --dport 443 -j DROPبه همین سادگی :)شاید خیلی جاها ببینید بجای -I از -A استفاده میکنن که به معنی Append هست و دیگه نیاز به شماره جایگاه نیست و خودش به آخر جدول اضافه میکنه. حالا میخوایم چک کنیم ببینیم دستوراتمون درست ذخیره شدن یا نه:iptables -nL --line-numbersبا این دستور همه جدول‌ها همراه با شماره گذاریشون نشون داده میشن.اگه بخوایم مثلا قانون شماره دوم رو حذف کنیم:iptables -D INPUT 2iptables -D (DELETE) (Table with Rule number)تصور کنید بخوایم برای ssh که روی پورت ۲۲ معمولا اجرا میشه قانون تنظیم کنیم. واضحه که ورودی مثل ۴۴۳ هست ولی از اونجایی که ssh دو طرفه هست و هر درخواست نیاز به پاسخ روی همون پورت داره پس ما باید توی جدول خروجی هم تنظیم کنیم که هر درخواستی از سرور ما به آدرس مورد نظر خواست بره اجازه خروج داره. نکته قابل توجه این هست که باید درنظر بگیریم پکت مورد نظر داره از پورت ۲۲ (Source port) خارج میشه و آدرس مقصدش (Destination) آدرس مدنظر ماست. پس داریم:iptables -I OUTPUT 1 -p tcp -d 10.10.10.10 --sport 22 -j ACCEPTiptables -I OUTPUT 2 -p tcp --sport 22 -j DROPاینجا ما تنظیم کردیم هرکسی قصد خروج از سرور با پورت ۲۲ داره و آدرس مقصدش ۱۰.۱۰.۱۰.۱۰ هست اجازه خروج داره و بعدش خروج همه پکت ها از پورت ۲۲ رو ممنوع کردیم. لازم به ذکر هست برای کار روی محیط Production نیاز به پرداختن به جزئیات بیشتری مثل فرق DROP و REJECT هست ولی برای درک اولیه موارد بالا کفایت میکنن.در مطالب بعدی سعی میکنیم درمورد ساختن جدول ها و اساسا مفهموم CHAIN بیشتر صحبت کنیم. راجع به تعامل داکر با iptables؛ و همچین درمورد جزئیات دستورات؛ آپدیت کردن قوانین؛ تنظیم رنج آدرس؛ دیباگ کردن قوانین و کلی موارد دیگه که روی محیط Production باید رعایت بشن. ممنون از همراهیتون. Mahdi Golbaz Mahdi Golbaz Sat, 04 Sep 2021 10:43:18 +0430 https://virgool.io/@nmgolbaz2012/%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D8%A8%D9%87-%D8%B9%D9%86%D9%88%D8%A7%D9%86-%DA%A9%D8%AF-%DB%8C%D8%A7-iac-%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%DA%AF%D8%B0%D8%B1%D8%A7-%D8%A8%D9%87-ansible-%D9%88-terraform-my3b5lyku37u توی این مطلب میخوایم سری بزنیم به حوزه‌ی جذاب و تقریبا بروز infrastructure as code و دوتا از بهترین ابزارها توی این زمینه یعنی Terraform و Ansibleاینها ابزارهایی هستند برای تهیه؛ پیکربندی؛ نگهداری و مانیتورینگ زیرساخت هایی که برای توسعه و استقرار سرویس‌ها و برنامه ها استفاده میشن.همونجور که توی مطالب قبلی هم اشاره کردیم؛ در زمان های قبل‌تر فرآیند توسعه بیشتر بصورت آبشاری بوده و شامل چرخه‌ای طولانی برای رسیدن به یک release بوده و آپدیت‌ها دیربه دیر و تفاوت خروجی‌ها در هر آپدیت زیاد بود.ولی امروزه با فراگیری پارادایم و الگوی توسعه چابک شرایط دستخوش تغییر شده و باعث به‌وجود اومدن مفاهیم جدیدی مثل IaC یا Infrastructure as Code شده.IaC — Infrastructure as Codeپیش از این در رویکرد سنتی سرورها بصورت دستی کانفیگ میشدن و همین باعث میشد تیم توسعه درگیر overhead هایی مثل تهیه داکیومنت دقیق جزئیات برای هر سرور بشه یا سازمان نیازمند یک تیم بزرگ برای ارائه خدمات زیرساخت باشه؛ همچنین باعث طولانی‌تر شدن بی‌اندازه چرخه توسعه و افزایش وابستگی بین تیم‌های توسعه میشد.هدف از IaC رفع این مشکلات با حذف کانفیگ‌های دستی و استفاده از کد برای تهیه و کانفیگ سرور هست. اسکریپت‌هایی که به صورت کد توسعه داده میشن و میتونن با کنترل نسخه مدیریت بشن؛ و هرزمان نیاز شد ازشون برای کانفیگ سرورها استفاده کرد. همچنین به راحتی بین تیم‌ها به اشتراک گذاشته میشن و هرکس میتونه دقیق از اتفاقاتی که روی هر سرور داره میوفته باخبر باشه.هر دو ابزار Terraform و Ansible برای رفع نیازها در توسعه زیرساخت استفاده میشن و در راستای اهداف IaC هستند و تقریبا توی همه موارد میتونن جای همدیگه استفاده بشن ولی درنهایت تفاوت‌هایی دارن که باعث میشه از هرکدوم توی زمینه‌های متفاوتی استفاده کنیم.- Terraform از ترافورم معمولا برای Provisioning یا ساخت ماشین‌های مجازی براساس نیازهای ما استفاده میشه. مثلا به ۳ سرور با منابع متفاوت داریم برای ساخت این ماشین‌ها روی سرور اختصاصی خودمون از ترافورم استفاده میکنیم. ترافورم قبل از ایجاد تغییر شرایط موجود روی سرور رو بررسی میکنه و بعد از اون با توجه به تغییراتی که تعریف شده و انتباق اون‌ها با شرایط موجود یک سری دستورالعمل تدارک میبینه و اونها رو اجرا میکنه. حالا مثلا بعد از چند روز متوجه شدیم توی نیازمندی هامون اشتباه کردیم و نیازی به ۳ سرور نیست و بناداریم یکی از اون هارو حذف کنیم یا مثلا یکی از سرورها نیاز به منابع بیشتری داره؛ توی این شرایط هم میشه در ترافورم دستورالعمل هایی تعریف کرد که نیازهای مارو برطرف کنه.- Ansibleانسیبل یک سرویس متن‌باز هست که توسط Red Hat توسعه داده شده و موارد استفاده‌اش بیشتر برای کانفیگ کردن محیط سرور و استقرار(Deploy) برنامه‌ها و سرویس ها روی سرور هست. یا مثلا اجرای یک پالیسی امنیتی روی همه‌ی سرورهای مدنظر(مثلا بلاک کردن یک آیپی روی ۱۰ تا سرور یا نصب پیش‌نیازها برای دیپلوی یک سرویس روی سرور)از تفاوت‌های عمده انسیبل و ترافورم میشه به Stateful/Stateless بودن اونها اشاره کردترافورم یک پلتفرم Stateful هست به این معنا که State سرورهارو به‌خاطر میسپاره و مثلا اگه یک تابع به اشتباه چندبار روی یک سرور اجرا شه ترافورم قابلیت تحلیل شرایط موجود روی سرور رو داره و فقط یکبار اون رو اجرا میکنه ولی انسیبل Stateless هست و اهمیتی به شرایط موجود روی سرور نمیده(واضح هست که نمیتونه چند بار مثلا یک سرویس رو نصب کنه و چک میکنه نصب بودن رو:)).یک تفاوت خیلی مهم بین این دو Procedural و Non-Procedural بودن اونهاستوی انسیبل ما با یک ساختار پرسیجرال روبرو هستیم که میشه توش براساس شرایط موجود روی سرور به برنامه دستورات جداگانه داد. مثلا میشه مشخص کرد که اگه روی سرور سیستم‌عامل Ubuntu نصب بود از دستورالعملA استفاده بشه و اگر از CentOS بود از دستورالعمل B. یا مثلا برای فرآیندهای تکراری میشه از حلقه(Loop) استفاده کرد.ولی توی ترافروم ما باید فقط اون چیزی که باید روی سرور وجود داشته باشه رو تحویل برنامه بدیم و اون خودش بر اساس شرایط موجود عمل کنه. در عمل امکان توصیف مجموعه‌ای از دستورات و توابع برای رسیدن به هدفمون رو نداریم.درنهایت باید بسته به نیاز از هرابزار توی جای درستش استفاده کرد.قطعا برای یادگیری و استفاده از اونها بهتون داکیومنت های هرکدوم رو پیشنهاد میکنم ولی سعی میکنم توی مطالب بعدی یک introduction برای هرکدوم براتون بنویسم:). Mahdi Golbaz Mahdi Golbaz Sat, 21 Aug 2021 07:38:45 +0430 https://virgool.io/@nmgolbaz2012/%D8%A7%D8%B3%D8%AA%D8%B1%D8%B3-%D8%A7%D8%B2-%D9%86%DA%AF%D8%A7%D9%87-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-failover-testing-poapquiqmjlq بازگشت از بحران یا Desaster Recovery Plan(DRP) یک برنامه مستند و ساختاریافته هست که مشخص میکنه یک سازمان درصورت بروز حادثه یا خطای پیش‌بینی نشده چطور میتونه در سریع‌ترین زمان ممکن به روال معمولِ خودش برگرده. هر سازمان که به مشتری های خودش ضمانتِ یک سرویس یا پشتیبانی میده نیازمند برنامه‌ای دقیق برای بازگشت از بحران هست.این برنامه به سازمان کمک میکنه چطور مشکلاتی نظیر از دست رفتن داده‌ها درصورت بروز خطا یا وجود مشکل در فانکشنالیتیِ یک سرویس رو برطرف کنه و در اون باید برای هر level از محصول یا سرویس برنامه‌ دقیق وجود داشته باشه.برنامه گام به گام شامل اقدامات احتیاطی برای به حداقل رساندن آثار یک فاجعه هست تا سازمان بتونه به فعالیت خود ادامه بده یا به سرعت وظایف مهم ماموریت را از سر بگیره. به طور معمول ، برنامه بازگشت از بحران شامل تجزیه و تحلیل فرایندهای تجاری و نیازهای متداوم هست. قبل از ایجاد یک برنامه، یک سازمان اغلب تجزیه و تحلیل تأثیرات تجاری (BIA) و تحلیل ریسک (RA) را انجام میده و اهداف Recovery رو تعیین می کنه.برخی از انواع حوادثی که معمولا سازمان‌ها برای اون برنامه‌ریزی میکنند رو با هم نگاه کنیم:Application failureCommunication failureData center disasterBuilding disaster....توی حوزه زیرساخت برای بازگشت از بحران؛ اولین مبحثی که باید بهش توجه کنیم Failover System یا سیستم بازگردانی هست.سیستم‌ بازگردانی یک فرآیند بکاپ‌گیری هست که درصورت بروز اشکال توی سیستم های اصلی؛ سرور‌ها؛ پایگاه‌داده ها؛ شبکه و سرویس‌ها رو به صورت اتوماتیک روی یک سیستم سالم سویچ میکنه. و معمولا روی سیستم‌هایی که نیاز به always-on accessibility دارند پیاده میشه.به عنوان مثال اگه سرور اصلی توی دیتاسنتر دچار مشکل بشه با توجه به زمان‌بر بودن فرآیند ریکاوری میشه نتیجه گرفت توی این زمان سرور پشتیبان بلافاصله بعد از بروز مشکل باید مسئولیت میزبانی رو به عهده بگیره.سیستم بازگردانی میتونه توی هرکدوم از اجزای یک سیستم به صورت مجزا هم پیاده بشه؛ مثلا برای storage یا برای پایگاه‌داده ها.تصور کنید چهار وب‌سرور زیر بار سنگین ریکوئست داریم و ناگهان یکی از اون‌ها دچار مشکل بشه؛مواردی که توی failover باید بررسی بشن: آیا load balancer میتونه واکنش درستی داشته باشه؟ یا اصلا سه سرور دیگه میتونن بار رو تحمل کنند یا اگه بار بین اونها تقسیم بشه بقیه سیستم های درگیر هم آسیب میبینن؟ آیاوب‌سرور خراب شده مجددا راه‌اندازی میشه یا نیاز به مداخله دستی داره؟ ایا سیستم اطلاع رسانی خودکار درست عمل میکنه؟حالا اولین سوالی که برای هرشخص ممکنه پیش بیاد این هست که چطور مطمئن شیم Failover system که طراحی کردیم درست کار میکنه؟- ⚠️Failover Testing⚠️ -متاسفانه تنها راهی که بشه مطمئن بود درصورت وقوع یک disaster یا فاجعه سیستم بازگردانی ما درست کار میکنه؛ شبیه سازی فاجعه است. یعنی بروز یک مشکل در Crazy Load به صورت دستی! به عنوان مثال برای تست Failover روی storage؛ SAN یا Storage area network فضای دیسک هست که بین server ها به اشتراک گذاشته میشه و فایل سیستمِ سرور‌های مجازی روی اون قرار میگیرن.اگه خواستین استرس کارتون رو با یه متخصص شبکه وزیرساخت مقایسه کنید خودتون رو تو لحظه‌ای قرار بدین که توی یک کلاستر با ۱۰۰ ترابایت فضا که ۷۰۰ تا VM روش داره کار میکنه و داره به ۵-۶ تا شرکت و ارگان سرویس می‌ده؛ قراره برای تست Failover؛ نودِ اکتیوِ SAN رو از برق بکشید!! از لحظه ای که SAN اکتیو رو از برق می‌کشی دیگه هیچ کنترلی روی چیزی نداری و زیرساخت فقط میتونه ۳۰ تا ۴۰ ثانیه تحمل کنه تا SAN پَسیو وارد مدار بشه وگرنه تمام VM ها و ESXi ها آسیب میبینن و همه مسئولیتش با شماست. تا وقتی روی VMware تو Datastore یه فولدر بسازی و فایل آپلود کنی و بعد حذفش کنی تا مطمئن بشی نه تنها Failover شده، از اون مهم تر داره درست کار می‌کنن حدود دو دیقه زمان میبره که اگه از من بپرسید میگم قطعا عمر آدم رو کوتاه میکنه xD. Mahdi Golbaz Mahdi Golbaz Sun, 15 Aug 2021 10:01:43 +0430 https://virgool.io/@nmgolbaz2012/%D8%AF%D9%88%D8%A7%D9%BE%D8%B3-%DB%8C%DA%A9-%D8%AA%D8%AE%D8%B5%D8%B5-%D9%86%DB%8C%D8%B3%D8%AA-hffbojvzi6fl این روزها در پی پیشرفت سریع تکنولوژی در سراسر دنیا؛ ارتباط بسیار نزدیک زندگی و اینترنت باعث شده هر روز نیاز به محصولات و خدمات مجازی بیشتر بشود. شرکت‌ها به دنبال توسعه سریع‌تر و بی‌نقص‌تر هستند و به رویکرد‌هایی نظیر چابک روی آورده ان. ظهور و پیشرفت محاسبات ابری (cloud computing) باعث به وجود آمدن روش‌های به صرفه‌تر و با ظرفیت بیشتر جهت ارائه محصولات شدن و همه‌ی اینها منجر به ایجاد تخصصی در حوزه نرم‌افزار با نام DevOps شده.دواپس در واقع یک فرهنگ و رویکرد جهت تسریع توسعه محصول و تضمین تحویل اون هست.این عبارت از اتصال دو کلمه توسعه و عملیات به وجود اومده. پیش از به‌جود اومدن این فرهنگ شرکت ها شامل دو تیم توسعه و عملیات بودند ولی برای بهینه‌تر کردن فرآیند نیاز به از بین بردن فاصله میان این دوتیم هست. درادامه سعی میکنم این چرخه رو خیلی کلی توی توسعه یک محصول توضیح بدم.چرخه دواپسهمونطور که در تصویر میبینیم چرخه از plan شروع میشه؛ توی این مرحله تیم برای توسعه محصول برنامه‌ریزی و زمان‌بندی میکنه و تسک‌ها به طور دقیق مشخص میشن. محصولاتی که توسط تیم توسعه داده میشن توسط ابزار های کنترل نسخه ذخیره و merge میشن. بعد از اون برای به وجود آوردن یک محیط ایزوله و متناسب با محصول (با استفاده از docker یا ابزار مشابه) یک image‌ تولید میشه؛ اگر کدها نیازمند Build شدن باشند توسط کانتینر انجام میشه و درنهایت روی محصول تست‌هایی(نظیرunit test) متناسب با نیاز انجام میشه و بعد از موفقیت در تست ها؛ درنهایت محصول release میشه. یکی از اصول دواپس؛ اتوماسیون هست و معمولا برای صرفه‌جویی در زمان و جلوگیری از بروز خطای انسانی نیاز هست تمامی مراحل توسط سیستم‌ها انجام بشه. برای همین نیازمند یک pipeline برای ادغام مستمر(Continuous Integration) و تحویل مستمر(continuous delivery or continuous deployment) هستیم. معمولا از لحظه پوش کردن کردن کد روی version control تا مرحله release رو ci درنظر میگیریم که توسط ابزار‌هایی مثل jenkins و gitlab-ci انجام میشه.پس از release؛ نیاز هست که محصول روی سرور مدنظر deploy بشه. معمولا تیم‌ها یک سرور برای Production و یک سرور برای develop؛ و یک سرور QA(Quality Assurance) که دقیقا مشابه سرور Production هست رو درنظر میگیرن. باتوجه به این که سرور‌ها بصورت جداگانه برای ارائه محصول تنظیم و کانفیگ میشن؛ ممکن هست تغییرات در زیرساخت هرسرور باعث به وجود اومدن مشکل بشه.(مثلا ورژن پایگاه‌داده روی یک سرور با دیگری متفاوت باشه و ایرادی که توی سرور production به وجود میاد روی سرور QA دیده نشه). برای همین برای کانفیگ کردن سرور‌ها از infrastructure as code یا توسعه زیرساخت توسط کد استفاده میشه که سرورها دقیقا مثل هم تنظیم بشن. از ابزار های مفید توی این زمینه میتوان ansible یا Terraform رو نام برد.خب گفتیم که سرورهایی که از قبل مثل هم کانفیگ شدن نیازمند دیپلوی هستند. این روزها ابزارهایی توسعه داده شدن که به محصول توانایی‌هایی نظیر اجرا روی زیرساخت ابری؛ یا توانایی scale up شدن میدن که از مهم‌ترین اونها میشه kubernetes رو نام برد. فرآیند دیپلوی؛ راه اندازی و مدیریت این سرویس ها؛ مراحل cd و operate رو توی چرخه دواپس تشکیل میده.درنهایت پس از اجرای محصول و تحویل اون به مشتری؛ جهت بررسی دقیق سرورها و جلوگیری از به‌وجود اومدن مشکل توی اونها نیازمند monitoring سرورها و سرویس‌های در حال اجرا(مثلا پایگاه داده) هستیم. برای این منظور از ابزارهایی مثل Zabbix یا Prometheus و Grafana استفاده میشه به این صورت که یک exporter روی سرورهای ارائه محصول درحال اجراست و دائم اطلاعات دقیق سرویس ها و منابع درحال مصرف رو به سرور monitoring میفرسته. به محض بروز اتفاقی خارج از استاندارد تعریف شده به تیم maintenance‌ گزارش داده میشه یا دستورات تعریف شده اجرا میشن.در چند سطر بالا سعی کردم یک توضیح بسیار کلی و ساده از فرآیند دواپس توی توسعه محصول بدم و مشخصه هربخش دارای جزئیات خیلی زیاد هست که درآینده به تفصیل ازشون مینویسم. Mahdi Golbaz Mahdi Golbaz Sun, 08 Aug 2021 06:04:09 +0430 https://virgool.io/@nmgolbaz2012/%D9%85%D9%81%D9%87%D9%88%D9%85-write-ahead-logging-%D8%AF%D8%B1-%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7-ewofo5wywklz همانطور که در پست قبلی گفته شد:اسید - ACID (Atomicity, Consistency, Isolation, Durability) به طور کلی تضمینی برای انجام صحیح تراکنش هاست و این خصوصیات وقتی از همزمانی(concurrency) در سیستم استفاده کنیم بیشتر به چشم میآید.به این معنا که عملیات هایی که در سیستم همزمان انجام میشوند با رعایت خواص اسید ضمانت میشوند.در این پست به یکی دیگر از مفاهیم ACID به نام Durability خواهیم پرداخت. Durability یا پایداری، به معنای ضمانت این امر است که یک تراکنش موفق و ثبت شده در صورت بروز حادثه یا ناپایداری در سیستم و پایگاه داده پس از احیا و پایدار شدن نیز در پایگاه داده به درستی اعمال شده است.برای این منظور پایگاه داده ها از WAL(Write ahead logging) استفاده میکنند.با توجه به اینکه سریع ترین پردازش در حافظه append کردن روی فایل میباشد؛ ایده اصلی پشت این تکنیک ثبت تمام تراکنش ها روی storage یا همان disk است پیش از آنکه اجرای آنها روی پایگاه داده باعث تغییر شود. در این صورت اگر پس از ثبت و log کردن عملیات های مدنظر و حین اعمال آنها در سیستم مشکلی پیش بیاید؛ سیستم میتواند تغییرات صحیح را از توی لاگ های موجود recovery کند. همچنین این لاگ ها به پایگاه داده ها قابلیت roll back نیز میتواند بدهد که الآن مورد بحث نیست.این فرایند تضمین می کند که هیچگونه تغییری در پایگاه داده روی دیسک منتقل نمی شود تا زمانی که لاگ های تراکنش مربوطه برای حفظ خواص ACID روی دیسک نوشته شود.نکته قابل تامل در مطالب بالا؛ این است که اساسا write روی حافظه disk نسبت به سرعت پردازش در سیستم ها بسیار کند است و باعث کاش performance میشود. معمولا سیستم عامل ها برای حل این مشکل از buffer استفاده میکنند به این صورت که داده ها روی memory به صورت دوره‌ای cache میشوند و با توجه به استراتژی اعمال شده روی کرنل؛ بافر روی دیسک اصلی Flush میشود.(به این عمل sync-ing گفته میشود)بدیهی است که اگر پایگاه داده بخواهد از همین استراتژی برای ذخیره لاگ ها استفاده کند در صورت قطعی برق ناگهانی یا بروز مشکل در سیستم؛ لاگ های روی memory نیز از دست میرود و عملا write ahead بی‌فایده بوده؛ ولی اگر از sync استفاده کند با کندی سیستم و کاهش performance مواجه خواهد شد.معمولا در پایگاه داده های مختلف بسته به نیاز محصول باید sync or non-sync را کانفیگ کرد؛ جزئیات این کانفیگ ها در داکیومنت های هرپایگاه داده به تفصیل یافت میشود ولی برای مطالعه کلی‌تر میتوانید به این مطلب مراجعه کنید. Mahdi Golbaz Mahdi Golbaz Sat, 31 Jul 2021 05:59:36 +0430 https://virgool.io/@nmgolbaz2012/transaction-isolation-levels-in-dbms-fd4tbua5wzvy وقتی بنا به صحبت راجع به دیتابیس ها داشته باشیم یکی از اصلی ترین مفاهیم که باید مدنظر ما باشد Transaction ها و ACID هست.اسید - ACID (Atomicity, Consistency, Isolation, Durability) به طور کلی تضمینی برای انجام صحیح تراکنش هاست و این خصوصیات وقتی از همزمانی(concurrency) در سیستم استفاده کنیم بیشتر به چشم میآید.به این معنا که عملیات هایی که در سیستم همزمان انجام میشوند با رعایت خواص اسید ضمانت میشوند.در میان این ویژگی ها؛ isolation مشخص میکند که یک تراکنش در نظر کاربران و سیستم‌های مرتبط به گونه‌ای محافظت شود که بتوان متصور شد تنها تراکنش در حال انجام در آن پایگاه داده است.حال میپردازیم به موضوع اصلی این نگارش: Isolation Levels - این سطوح مشخص میکنند هر تراکنش در چه لایه‌ای باید از تراکنش در برابر تغییرات اعمال شده از سوی دیگر تراکنش ها محافظت کند.این سطوح در پایگاه داده SQL به ترتیب زیر میباشد:Read Uncommitted :- سطحی ترین لایه جداسازی است که عملا در این سطح یک تراکنش میتواند تغییرات commit نشده توسط یک تراکنش دیگر را بخواند. اصطلاحا به این خوانش «dirty read» گفته میشود. در این لایه isolation وجود ندارد.Read Committed:- در این لایه پایگاه داده ضمانت میکند هر تراکنش تنها دسترسی به تغییرات commit شده دارد و dirty read در آن ممکن نیست.Repeatable Read:- این لایه تقریبا مشابه لایه قبلی عمل میکند با این تفاوت که تا زمانی که تمامی خوانش ها در یک ردیف انجام نگیرد تراکنش را قفل کرده و امکان ایجاد تغییر روی داده را به دیگر تراکنش ها نمیدهد.Serializable:بیشترین سطح جداسازی و انزوا برای تراکنش ها در این لایه صورت میگیرد. در این لایه پایگاه‌داده عملیات هایی که به صورت همزمان قرار است در سیستم انجام شود را به صورت serially و پشتِ‌سرِ هم انجام میدهد و به طور کامل از رخدادِ Phantom Reads در پایگاه داده جلوگیری میکند. (هنگامی که دستور SELECT ما با یک عملیات تغییر در پایگاه داده همزمان شود و آن تراکنش قصد اثر گذاشتن بر خوانش ما داشته باشد میگوییم Phantom Reads رخ داده است)-- هنگام انتخاب زبان یا Framework برای توسعه یک سیستم داده‌محور؛ از مهمترین نکات قابل بررسی میتوان به ORM آن زبان و میزان پشتیبانی آن از لایه های جدا سازی؛ و ارزیابیِ آن با توجه به نیازمندی سیستم اشاره کرد. Mahdi Golbaz Mahdi Golbaz Sat, 24 Jul 2021 04:08:57 +0430