نوشته های حامد خاکباز

آشنایی با XHR و Fetch در JavaScript

حامد خاکباز — Sat, 08 Oct 2022 15:05:12 +0330

منظور از XHR چیست؟ چه تفاوتی بین XHR و Fetch وجود دارد؟ منظور از Promise در JavaScript چیست؟ چه تفاوتی بین Promise و callback وجود دارد؟ در این مقاله به تحلیل و بررسی API های XHR و Fetch در صفحات وب می‌پردازیم.امروزه یکی از کارهای رایجی که در مرورگر انجام می‌شود ایجاد درخواست های HTTP با JavaScript هست. این کار توسط یک API به نام XMLHttpRequest یا XHR انجام می‌شود. در کد JavaScript زمان ارسال HTTP message نیاز هست که متد، هدر و بدنه‌ی request مشخص شود. یا در زمان دریافت HTTP response نیاز هست که Satus Code ها ، Header ها و ... تشخیص داده شوند. از این رو در زبان JavaScript ضرورت نیاز به سازوکاری که بتواند instance object هایی برای پیش‌بردن درخواست ها، (تحت flow پروتکل HTTP ) ایجاد کند، احساس شد.که این instace object ها با عنوان XHR شناخته می‌شوند.معرفی XHR در JavaScriptنسخه‌های اولیه XHR ابتدا در سال 1999 توسط Developer های مایکروسافت و به شکل غیر رسمی در Internet Explorer 5.0 معرفی شد و به مرور توسعه یافت. درواقع XHR یک نوع API هست که توسط زبان‌های اسکریپتی مثل JavaScript ، JScript ، VBScript و ... برای تبادل اطلاعات XML با وب‌سرور تحت HTTP استفاده می‌شود، که منجربه ایجاد یک کانال اشتراکی بین Client-side و Server-side تحت وب می‌شود. به عبارت بهتر HttpRequest ها در JavaScript با XHR ارسال می‌شوند. در واقع XHR بنیان و اساس پشت مفهوم AJAX هست و مهمترین تکنیکی هست که در AJAX استفاده می‌شود. پیش از XHR صفخات وب برای هر partial update ای باید کامل refresh می‌شدند چرا که AJAX وجود نداشت که به کمک XHR تنها بخش‌های مورد نیاز را آپدیت کند.همچنین XHR کمک می‌کند که کلاینت بتواند در مرورگر با JavaScript برای وب‌سرور script data ارسال کند. XHR کمک کرد که عملیات‌ها به شکل Async و تحت کنترل کامل کد‌های JavaScript انجام شود. در حقیقت با آمدن XHR جهش بزرگی در رشد وب‌اپلیکیشن‌های interactive صورت گرفت.تفاوت XHR با Fetchاما XHR تنها API ای که توسط AJAX استفاده می‌شود، نیست. بلکه بجز XHR جدیدن یک API مدرن دیگری به نام Fetch نیز وجود دارد که جایگزینی برای XHR محسوب می‌شود. در واقع Fetch برای عملیات واکشی از سرور مناسب‌تر هست. همچنین در کد این دو API نیز تفاوت‌هایی وجود دارد، مثلن در XHR از ()request.open و send() استفاده می‌کنیم ولی در Fetch تنها با متد fetch() همان کار انجام می‌شود. تفاوت اصلی Fetch با XHR در این است که Fetch از Promise استفاده می‌کند. Promise یک آبجکت در JavaScript است که باعث تعیین وضعیت و انجام عملیات‌های Async می‌شود. JavaScript به کمک Promise می‌فهمد که آیا عملیات‌های Async موفقیت آمیز شده‌اند یا خیر. یا در چه وضعیتی هستند؟ Pending یا Reject شده اند. از این رو Promise ها روی عملیات‌های وب‌اپلیکیشن‌های مدرن خصوصن در مواقعی که بیش از یک درخواست Async در تبادل هست بسیار مفید و موثر هست.در JavaScript دو متد اصلی برای انجام عملیات‌های Async وجود دارد:الف) Callback :به عملیات یا function ای که خود در دل function دیگر انجام می‌شود، Callback گفته می‌شود. این مورد باعث انجام کارها به شکل Async می‌شود. در واقع callback به عنوان یک آرگومان getData در کد JavaScript استفاده می‌شود.ب) Promise :استفاده از Promise به معنی حذف کردن callback ها نیست. بلکه زنجیره‌ای از function ها را در بر می‌گیرد که عملیات Async را راحت‌تر می‌کند. همچنین Promise از syntax راحت‌تر و user-friendly تری برای خواندن استفاده می‌کند و مدیریت error handling نیز در Promise راحت‌تر است.به عنوان نتیجه‌گیری؛ XHR در تمام مرورگرها پشتیبانی می‌شود ولی Fetch در Internet Explorer و دیگر نسخه‌های قدیمی پشتیبانی نمی‌شود. بنابراین اگر در حال توسعه وب‌اپلیکیشن‌ای هستید که قرار است روی مرورگرهای قدیمی کار کند بهتر است از XHR استفاده کنید. ولی اگر وب‌اپلیکیشنی که تولید می‌کنید نیاز به پشتیبانی از نسخه‌های قدیمی ندارد بهتر است از Fetch برای AJAX و درخواست‌های Async استفاده کنید.

آشنایی با فرمت WebP در تصاویر وب

حامد خاکباز — Sat, 08 Oct 2022 10:04:46 +0330

فرمت WebP چیست؟ فرمت WebP چه نیازهایی را پوشش می‌دهد؟ چگونه می‌توان فرمت WebP را روی صفحات وب فعال‌سازی کرد؟ منظور از Predictive coding چیست؟ در این مقاله به تحلیل و بررسی فرمت WebP می‌پردازیم.امروزه بسیاری از صفحات وب از تصویر برای ارایه اثربخش‌تر دیتا استفاده می‌کنند. اما وجود عکس به خودی‌خود در صفحه وب سرعت لود سایت را کند می‌کند. خصوصن در سایت‌هایی که در صفحات خود تعداد زیادی تصویر قرار داده‌اند، سرعت لود روی مرورگر به شدت کندتر می‌شود. از طرفی فشرده سازی تصاویر، کیفیت آن را از بین می‌برد و همچنین نمی‌توان ابعاد همه‌ی تصاویر را کوچک‌تر کرد و یا آن را به فرمت کم‌حجم تری که کیفیت آن را تحت تاثیر قرار می‌دهد تبدیل کرد. از این رو ضرورت نیاز به یک فرمت‌ای که این دغدغه‌ها را پوشش دهد به شدت احساس می‌شد. تا اینکه با ابدا الگوریتم‌های جدید و پیدایش فرمت‌هایی نظیر WebP این نیاز تا حد زیادی پوشش داده شد.معرفی فرمت WebP در تصاویر فرمت WebP خود یک نوع الگوریتم فشرده‌سازی هست که در سال 2010 توسط developer های شرکت google معرفی شد. هدف از develop این فرمت ایجاد یک جایگزین سبک برای jpeg ، png ، gif و ... بود. فرمت WebP بدون از دست دادن المان های اصلی image ، آن را فشرده‌سازی و سبک می‌کند. به عبارت فنی‌تر فرمت WebP یک فرمت اصطلاحن lossless هست که تا جای ممکن کیفیت را تحت تاثیر قرار نمی‌دهد. طبق تست‌های انجام شده اگر یک عکس png به webp تبدیل شود تا 26 درصد کوچک‌تر وسبک‌تر می‌شود. به این ترتیب WebP باعث ایجاد user experience بهتری در سایت می‌شود. چراکه تایم کاربر کمتر هدر میرود، از طرفی هم باعث تسهیل فرآیند لود سایت در مرورگر می‌شود. همچنین WebP خصوصن در سایت‌هایی که تعداد بالای تصاویر را لود می‌کنند باعث صرفه‌جویی و کاهش سایز فضای درنظر گرفته شده برای ذخیره‌سازی در Storage نیز می‌شود.اما الگوریتم‌های WebP چگونه کار می‌کنند؟ برای این‌که کیفیت تصویر کم نشود، WebP در فرآیند encode و decode خود از روش Predictive coding استفاده می‌کند، در این روش از روی اطلاعات pixel های اطراف برای حدث زدن سایر block ها استفاده می‌شود و کدک آن به شکلی هست که تنها فریم‌های اساسی را compress می‌کند و موارد غیرضروری را نادیده‌ می‌گیرد. در واقع predictive coding یک شیوه‌ی نوین و منحصربه‌فرد برای ساخت و کانورت تصاویر است. چراکه از الگوریتم‌هایی استفاده می‌کند که pixel ها را آنالیز کرده و می‌تواند سایر pixel ها و رنگ‌های اطراف را پیش‌بینی کند.به طور کلی در تصایر دو نوع compression وجود دارد :الف) نوع Lossless: در این نوع compression تعداد بیت های دیتا کمتر می‌شود ولی کیفیت تصویر کاهش نمی‌یابد. ب) نوع Lossy: در این نوع compression علاوه بر کاهش سایز تصویر، کیفیت آن نیز کاهش می‌یابد.فرمت WebP در compression از نوع Lossless استفاده می‌کند. به فرمت webp در برخی ابزارها next-generation format هم گفته می‌شود. همچنین از معایب استفاده از WebP می‌توان به پشتیبانی نشدن در برخی مرورگرها مثل نسخه های قدیمی safari و internet explorer اشاره کرد، همچنین WebP برای استفاده در سایت‌هایی که می‌خواهند تصایر را با بیشترین حد کیفیت ارائه کنند مناسب نیست چراکه در نمایش جزییات تصایر کیفیت بالا نمی‌تواند از کاستن کامل کیفیت جلوگیری کند.اما برای اینکه WebP را روی سایت پیاده‌سازی و فعال کنیم، روش‌های زیادی وجود دارد، مثلن در wordpress پلاگین‌هایی هست تحت عنوان image optimizer که فرمت WebP را پشتیبانی می‌کنند. یعنی حتا اگر فایل‌های اصلی WebP نباشند، به کمک این پلاگین‌ها به شکل اتوماتیک تصاویر پیش از نمایش به فرمت WebP کانورت می‌شوند. این کار را سرویس‌های توزیع محتوا یا CDN ها نیز انجام می‌دهند. که در CDN آروان تحت عنوان قابلیت شتاب‌دهی وب شناخته می‌شود.استفاده از فرمت WebP باعث بالا رفتن rank سایت در گوگل می‌شود. در واقع فرمت WebP امروزه به عنوان یکی از فاکتورهای حیاتی SEO محسوب می‌شود. به طور خلاصه؛ توصیه می‌شود فرمت‌هایی نظیر jpeg و png برای کاربران سایت به WebP تبدیل شوند. CDN ها این قابلیت را می‌توانند به ساده‌گی فراهم کنند.

آشنایی با CORS در وب و Headerهای آن

حامد خاکباز — Fri, 07 Oct 2022 20:01:53 +0330

منظور از CORS چیست؟ درخواست‌های Cross-Origin چه خصوصیاتی دارد؟ مفهوم Origin Policy به چه چیزی اطلاق می‌شود؟ CORS چه کاربردهایی دارد؟ منظور از Same-Origin Policy چیست؟ هر کدام از Headerهای CORS چه کاربردی دارند؟ در این مقاله به دنبال آشنایی با مفاهیم پیرامون CORS و کاربرد Headerهای آن‌ها هستیم.در سال 1995 مفهوم و concept ای معرفی شد که به دنبال ایجاد سازوکاری اتوماتیک و امنیتی برای مدیریت دسترسی و همچنین جلوگیری از دسترسی مدیریت نشده‌ی اسکریپت‌های یک سرور به دیگر سرورها یا منابع سایر سرورها بود. این concept امروزه تحت عنوان origin policy شناخته می‌شود. هدف از origin policy ایجاد یک trust relationship بین کاربر و منابع تحت وب هست.اما در دنیای وب در بسیاری از مواقع درخواست‌هایی که تحت صفحات وب ارسال می‌شود ممکن است برای لود منابع سرور یا origin ثانویه و دیگری باشد. یعنی در حقیقت کاربر دارد از origin دیگری منابع و دیتا را دریافت می‌کند. به این ترتیب که یک درخواستی روی یکorigin ، در اصل دارد منابع origin دیگری را طلب می‌کند. به این نوع درخواست‌ها cross-origin گفته می‌شود. مثلن یک صفحه‌ی وب مانند https://example.com/we.html خود در حال لود منابع از آدرس https://kingtest.com است. حتا درخواست‌ها به یک Host واحد تحت پروتکل‌های مختلف هم cross-origin محسوب می‌شود. یعنی مثلن http://kingtest.com/null.html خود در حال زدن درخواست به https://kingtest.com/main.html است. در نظر داشته باشید که منظور از origin همان هاست نیست، بلکه origin عبارت است از ترکیب پروتکل، هاست و path . پس اگر هر کدام از این سه تغییر کند، درخواست می‌شود از نوع cross-origin . (یعنی به origin دیگر)اما cors policy خود در دو بخش Same-Origin و Cross-Origin به نوعی تفکیک شده است که در ادامه به صورت مجزا به بررسی این دو می‌پردازیم.معرفی Same-Origin Policy یا SOPیکی از سازوکارهای امنیتی که امروزه در هر مرورگر وجود دارد same-origin policy هست. این قابلیت در مرورگر باعث کنترل ارتباط اسکریپت‌های در حال اجرا با منابع دیگر روی همان origin می‌شود و محدودیت‌هایی برای جلوگیری از سواستفاده از منابع وب‌سرور در مرورگر اعمال می‌کند. در واقع SOP در مرورگر جلوی دسترسی مدیریت نشده‌ی مثلن Javascript (و سایر زبان‌های اسکریپت نویسی وب) را به web document ها می‌گیرد و تغییراتی که از سمت programming interface ها تحت وب روی داکیومنت‌ها اعمال می‌شود را کنترل می‌کند. این امر جلوی سواستفاده‌ی هکرها و اسکریپت‌های مخرب در وب را تا حدودی می‌گیرد. SOP برای ایجاد trust relationship از URI ها استفاده می‌کند. اما SOP مدیریت چندانی روی ارتباط بین origin های مختلف ندارد. از این رو برای اعمال کامل origin policy روی ارتباط بین سرورهای متفاوت به سازوکار مکمل دیگری نیز احتیاج داریم که CORS نامیده می‌شود.معرفی Cross-Origin Resource Sharing یا CORSاما SOP در کنار تمام مزیت‌هایی که داشت، کمی سخت‌گیرانه بود و زیادی جلوی ارتباط (کدهای مثلن Javascript ) با منابع سایر origin ها را می‌گرفت در حالی که کاربران امروزی موقع کار با وب نیاز به دسترسی به منابع سایر origin ها را نیز دارند و نمی‌توان این نیاز را نادیده گرفت. از این رو CORS باعث می‌شود برخی محدودیت‌های SOP تحت شرایطی bypass شود زیرا CORS به دنبال ساده کردن مدیریت resource sharing بین سرورها تحت وب هست. همانطور که می‌دانید بنا به دلایل امنیتی مرورگرها روی درخواست‌هایی که تحت HTTP به صورت cross-origin ارسال می‌شوند، محدودیت‌هایی قرار می‌دهند. یعنی اگر شما بخواهید از یک اپلیکیشن frontend ای به API ای (که در origin دیگری قرار دارد) دسترسی پیدا کنید، به صورت پیش‌فرض مرورگر و سرور مقصد اجازه‌ی انجام این درخواست را نمی‌دهند.در واقع CORS به مرورگرها و وب‌سرور ها امکان نوعی سنجش می‌دهد، سنجش و بررسی اینکه آیا در فرآیند resource sharing ممکن است تهدیدی وجود داشته باشد یا خیر. از این رو CORS با هدف سیاست‌گذاری و کنترل ریکوست‌های cross-origin ایجاد شده است. به عبارت دیگر CORS باعث ایجاد سازوکاری برای کنترل دسترسی به منابع origin های دیگر است. با CORS می‌توان مجموعه‌ای از rule ها را تعریف کرد و مشخص کرد که چه نوع درخواست‌هایی توسط وب‌سرور پاسخ‌ داده شود، همچنین مشخص کرد که از کجاها و با چه متدی به منابع دسترسی وجود داشته باشد. به صورت پیش‌فرض rule ای ست نشده است و دسترسی‌ها بسته هست و SOP با تاثیر غیرمستقیم‌اش اجازه‌ی این ارتباط را نمی‌دهد. اما CORS برای تعریف این rule ها و تعیین شرایط دسترسی از تعدادی Header استفاده می‌کند که در ادامه به معرفی چند مورد از مطرح‌ترین آن‌ها خواهیم پرداخت.هدر Access-Control-Allow-Originاین Header مشخص می‌کند که کدام origin می‌تواند به منابع وب‌سرور دسترسی داشته باشد. این هدر سمت مقصد ست می‌شود و توسط مقصد برای مرورگر ارسال می‌شود و به مرورگر می‌گوید که چه origin ای اجازه‌ی دسترسی به منابع‌اش را دارد. مثلن وب‌سرور A تعیین می‌کند که تنها origin با مشخصات https://kingtest.ir به منابع‌اش دسترسی داشته باشد. اگر وب‌سرور A بخواهد کلن محدودیت را برای همه بردارد، می‌تواند مقدار این Header را مثلن برابر * قرار دهد تا تمام origin ها به منابع‌اش دسترسی پیدا کنند.هدر Access-Control-Allow-Methodsدر این Header مقصد(وب سرور A ) به مرورگر اعلام می‌کند که چه HTTP method هایی را در درخواست‌ها می‌پذیرد. مثلن POST ، GET یا ...هدر Access-Control-Allow-Headersتوسط این Header، سایر Headerهای ارسالی که وب سرور می‌پذیرد تعیین می‌شود.معرفی Preflight request ها در CORSاما زمانی که قرار هست در ارتباط با وب‌سرور یک‌سری Headerها چک شوند، نیاز هست که خود این اطلاعات از وب‌سرورها درخواست شوند تا اگر خطایی رخ داد و یا دسترسی origin ای باز نبود، بفهمیم روی کدام rule شرایط رعایت نشده و به عبارت بهتر وب‌سرور چه شرایطی را روی Headerهای CORS تعریف کرده است. این امر به کمک Preflight request صورت می‌گیرد.مکانیسم CORS برای فرآیند request permission از قابلیت Preflight request استفاده می‌کند. در واقع Preflight request ها پیش‌درخواست‌هایی هستند که توسط مرورگرها به سمت سرورها ارسال می‌شود، برای چک کردن اینکه آیا اصلن rule ای ست شده است؟ یا خیر. یا اینکه سرور به چه Headerها و متدهایی اجازه‌ی ارتباط می‌دهد.به عنوان نتیجه‌گیری و به طور خلاصه؛ CORS یک مکانیسم header-based است که rule ها و قوانینی را برای استفاده از منابع وب‌سرور تعیین می‌کند. شایان ذکر است که CORS به معنای تامین امنیت نیست و وجود SOP و پیاده سازی CORS امنیت کامل سایت را تامین نمی‌کند.

آشنایی با AJAX و کاربردهای آن

حامد خاکباز — Thu, 06 Oct 2022 15:16:47 +0330

منظور از AJAX چیست؟ AJAX چه کاربردهایی دارد؟ چطور می‌توان از AJAX استفاده کرد؟ AJAX چه مزایا و معایبی دارد؟ در این مقاله به دنبال معرفی AJAX و کاربردهای آن می‌پردازیم.در وب اپلیکیشن‌های قدیمی، مدل ارتباطی کلاینت-سروری به نحوی بود که کاربران از اینکه باید منتظر reload مداوم صفحات وب می‌ماندند، خسته می‌شدند. چرا که هر زمان که کاربر در وب روی هر چیزی(حتا جزیی) کلیک می‌کرد، مرورگر یک درخواست‌ reload به سرور ارسال می‌کرد. وب سرور نیز در جواب مجبور بود یک صفحه‌ی HTML و CSS جدید را به طور کامل برای کلاینت از نو ارسال کند. کاربر نیز باید پشت سیستم منتظر می‌ماند تا در مرورگر تمام صفحه هر بار کامل رفرش شود. همچنین درخواست‌هایی که به سمت وب سرور ارسال می‌شد، به شکلی نبود که کاربر بتواند هر وقت خواست (مستقل از سازوکار HTTP ) با وب سرور interactivity داشته باشد. از این رو developer ها به دنبال روش‌هایی رفتند که چابکی بیشتر را برای ارتباطات وب به ارمغان بیاورد که یکی از آن‌ها AJAX استآشنایی با AJAX و کاربردهای آنکارهای وب با AJAX نسبت به قبل کمتر زمان می‌برند. در واقع AJAX باعث بهبود interactivity در صفحات وب می‌شود. بدون AJAX صفحات مدام reload می‌شدند در حالی که تنها فقط یک جمله یا یک عکس در صفحه تغییر کرده است. اما با AJAX تنها آن بخشی که نیاز هست و آن چیزی که واقعن کاربر نیاز دارد از سرور آپدیت می‌شود. در واقع AJAX یک تکنیک آپدیت کردن بخشی از سایت و صفحه‌ی وب هست، بدون این‌که نیاز به reload کردن تمام محتوای سایت باشد. چراکه در background در حال ارسال دیتا به سمت سرور هست.به عبارت بهتر صفحه کامل رفرش نمی‌شود چون AJAX در پشت صحنه در حال آپدیت بخش‌های موردنیاز هست. همچنین AJAX درخواست‌ها را به شکل Async ارسال می‌کند، تا زمان کمتری صرف update دیتاهای درخواستی کاربر شود.از طرفی AJAX باعث responsive تر شدن صفحات وب می‌شود، چراکه بدون اینکه نیاز به reload کامل صفحه باشد کاربر می‌تواند بخش‌های کوچکی از صفحه را reload یا رفرش کند. این باعث می‌شود کاربری که از آن وب اپلیکیشن استفاده می‌کند بتواند بدون وقفه تغییرات اعمال کند. این امر منجر به کاهش ترافیک سرور، کاهش میزان استفاده از پهنای باند و افزایش سرعت وب می‌شود.اما AJAX در ماهیت خود یک ابزار یا زبان برنامه‌نویسی نیست. بلکه AJAX به کمک تکنیک‌هایی نظیر XMLHttpRequest و همچنین زبان Javascript یک رویکرد جدید برای develop کردن وب اپلیکیشن‌ها ایجاد کرده است. به عبارت بهتر AJAX خود یک تکنولوژی جدید نیست بلکه یک روش جدید برای استفاده از تکنولوژی های موجود است، یعنی یک اسکریپت کلاینت-سروری هست که بدون نیاز به فرآیند postback ، با سرور و دیتابیس تبادل اطلاعات می‌کند. همپنین تکنیک AJAX باعث ساخت وب‌اپلیکیشن‌های بهینه‌تر، سریع‌تر و باهوش‌تر می‌شود.از طرفی AJAX باعث ایجاد یک متد ارتباطی تحت وب، بین کلاینت و سرور شده که می‌تواند این ارتباط را بدون نیاز به reload کردن کل صفحه پایدار نگه دارد. به عبارت فنی تر AJAX امکان partial update را در صفحات وب فراهم می‌کند. این باعث شده که کاربران نسبت به قبل کنترل و قدرت تصرف بیشتری در تعامل با وب اپلیکیشن‌ها داشته باشند.اما AJAX نیز خالی از ایراد نیست و در مواقعی می‌تواند معایبی نیز داشته باشد. از جمله معایب AJAX می‌توان به مشکل ایندکس، امنیت نه چندان زیاد، دشواری رفع عیب و وابستگی به Javascript اشاره کرد.همچنین از مهم‌ترین و عمده‌ترین کاربردهای AJAX می‌توان به صفحات Login ، رای‌گیری و Rating و همچنین مواردی که نیاز به Auto-complete و Content update هست، اشاره کرد.به عنوان نتیجه‌گیری؛ اگر بخواهیم صفحات وب ای داشته باشیم که مانند اپلیکیشن‌های دسکتاپ interactive و responsive تر باشند باید از مجموعه راهکار AJAX استفاده کنیم. چراکه با AJAX صفحات وب درخواست‌ها را اصطلاحن به شکل Asynchronous ارسال می‌کنند تا کاربر به جای اینکه مثل سابق منتظر پاسخ‌اش بماند بتواند بی‌وقفه به کار خود ادامه دهد.

آشنایی با پروتکل WebSocket و کاربردهای آن

حامد خاکباز — Tue, 04 Oct 2022 16:34:11 +0330

منظور از WebSocket چیست؟ WebSocket چه کاربردهایی دارد؟ چطور می‌توان یک ارتباط WebSocket داشت؟ WebSocket چه مزایا و معایبی دارد؟ در این مقاله به دنبال معرفی WebSocket و کاربردهای آن می‌پردازیم.همانطور که می‌دانید پروتکل HTTP امروزه معروف ترین و یکی از پرکاربرد ترین پروتکل در صنعت IT و شبکه‌های کامپیوتری و سرویس وب هست.اما با وجود تمام مزیت هایی که در این پروتکل وجود دارد باز هم برخی از نیازهای وب اپلیکیشن‌ها و ارتباطات وب را پاسخ گو نیست. یکی از مهم‌ترین نقاط ضعف این پروتکل این هست که متد ارتباطی آن one-directional هست. در حالی که وب اپلیکیشن‌های امروزی برای این‌که عملکرد بهینه تری داشته باشند به متد ارتباطی two-way نیاز دارند. از این رو اکثر وب سرورها در نسخه های جدید WebSocket را اضافه کرده اند و آن را پشتیبانی می‌کنند.آشنایی با WebSocketدر واقع WebSocket یک تکنولوژی جدید برای تبادل دیتا هست که یک کانال ارتباطی دوطرفه با remote host برقرار می‌کند.. به عبارت فنی تر WebSocket ارتباط two-way را در یک محیط کنترل شده با کلاینتی که در حال اجرای یک untrusted code هست، برقرار می‌کند. در این ارتباط مرورگر از مدل امنیتی origin-based استفاده می‌کند. این باعث می‌شود ارتباط روی مرورگر با سرور و TCP handshake آنها، جوری برقرار شود که بدون نیاز به کانکشن های اضافی ارتباط دوطرفه ی ایمن برقرار شود.همچنین سازوکار HTTP در حال حاضر کند هست چراکه وقتی تحت HTTP درخواست دریافت یک فایل ارسال می‌شود، باید منتظر پاسخ کامل سرور ماند و real-time نمی‌توان به آن دیتا درستی یافت، این تاخیر مانعی جدی برای بهینه سازی ارتباطات web-based هست. در حالی که تحت WebSocket این کندی و تاخیر برطرف شده و این ضعف به نوعی پوشش داده شده است. به طور خلاصه؛ هدف اصلی WebSocket تبادل دوطرفه ی دیتا به‌شکل low-latency هست.اما برخی از کاربردهای اصلی WebSocket عبارت اند از؛ بازی‌های آنلاین، نوتیفیکیشن های لحظه‌ای اپلیکیشن‌ها، دریافت اطلاعات لحظه‌ای هواشناسی، تغییر لحظه‌ای قیمت‌ها و هر اپلیکیشن‌ web-based و browser-based ای که نیاز به ارسال و دریافت بلادرنگ دیتا دارند و ... .همچنین برای پیاده سازی WebSocket در پروژه ها سه المان اصلی و در واقع سه گام و مرحله پیاده‌سازی نیاز هست:۱- سمت کلاینت؛ استفاده از مرورگری که روی آن WebSocket پیاده سازی شده۲- دولوپر؛ انجام کد نویسی سمت وب و سرور۳- سرور؛ استفاده از وب سروری که WebSocket را به طور کامل ساپورت کند.اما WebSocket از نظر ظاهری و اصطلاحن URL Scheme به جای //:http از //:ws و //:wss استفاده می‌کند. به عنوان مثال آدرس هاست در WebSocket به شکل ws://example.com معرفی می‌شود.اما از معایب WebSocket می‌توان به نداشتن edge caching (برخلاف HTTP ) و همچنین دشواری و پیچیدگی Develope آن اشاره کرد. همچنین برای WebSocket مرورگر باید حتمن HTML5 را ساپورت کند. از طرفی WebSocket مکانیسم هایی شبیه AJAX را نیز به طور کامل ساپورت نمی‌کند.از طرفی کانکشن های WebSocket برای این ایجاد شده اند که با دوام تر از HTTP باشند. همچنین اگر نیاز شما این باشد که مثلن هر نیم ساعت یک‌بار آپدیت دریافت کنید؛ HTTP برای استفاده در این پروژه بهتر است. ولی اگر هر ثانیه به آپدیت نیاز دارید؛ WebSocket مناسب تر هست، چرا که بسیار سریع‌تر از HTTP کانکشن را Establish می‌کند.همچنین برای کدنویسی WebSocket نیاز به زبان برنامه نویسی خاصی نیست و در اکثر زبان ها ماژول WebSocketModule وجود دارد. مثلن در ASP.NET 4.5 المان نشان دهنده‌ی استفاده از این ماژول هست. یا در Python هم با import websockets می‌توان از WebSocket استفاده کرد.به عنوان جمع‌بندی؛ WebSocket یک نوع تکنیک push هست که روی یک TCP Socket کانال ارتباطی full-duplex طور ایجاد می‌کند و برخلاف HTTP از مدل‌های request-response و SYN/ACK استفاده نمی‌کند.

کاربرد Procfile چیست؟ آشنایی با Procfile و کاربردهای آن

حامد خاکباز — Mon, 29 Aug 2022 17:34:31 +0430

منظور از Procfile چیست؟ Procfile چه کاربردی در Git دارد؟ چطور می‌توان یک Procfile ساخت؟ محتوای Procfile را چگونه باید نوشت؟ در این مقاله به دنبال معرفی Procfile و آشنایی با نحوه‌ی ساخت Procfile برای یک اپلیکیشن یا پروژه جهت استقرار در سکوی ابری آروان به صورت مستقیم از روی یک Repository در Github هستیم.هنگامی که قصد ساخت یک اپلیکیشن از روی پروژه Github خودمان را داریم باید درون ریشه Repository فایل‌های مورد نیاز برای عملیات Build را معرفی کنیم تا Repository ما توسط Builder آروان قابل شناسایی باشد. یکی از این فایل‌ها که بودنش در هر Repository ای نیاز هست، فایل Procfile نامیده می‌شود. هر developer ای برای اینکه مشخص کند برای اجرای اپلیکیشن اش چه کامندی باید اجرا شود، باید Procfile آن پروژه را نیز بنویسد.آشنایی با Procfile و معرفی کاربردهافایل Procfile حاوی محتویاتی هست که منجر به اجرا شدن خودکار اپلیکیشن بر روی سکوی ابری می‌شود. اما محتویات این فایل دارای Template و قالب خاصی هست که بر اساس نوع کد و کاری که در پروژه قرار است انجام شود تعیین می‌شود و برای هر پروژه می‌تواند دربردارنده مقادیر متفاوتی باشد. به عنوان مثال در فایل Procfile می‌توان دستوری که قرار است توسط اپلیکیشن پایتونی و یا NodeJS ای اجرا شود را قرار داد. یا به کمک Procfile می‌توان مشخص کرد چه نوع proccess ای در اپلیکیشن با چه کامندی اجرا شود.به عنوان مثال در Procfile زیر مشخص شده است که کد با NodeJS نوشته شده و یک web application server قرار است با دستور npm start اجرا شود:یا به عنوان مثال از Procfile زیر می‌توان فهمید که یک پروژه Python قرار است اجرا شود:اما یک Procfile بسته به پروژه ممکن است محتوای پیچیده باشد و چندین نوع proccess را در خود جای داده باشد. مانند Procfile زیر:در Procfile فوق به ازای هر خط یک نوع proccess و دستوری که آن را اتوماتیک اجرا می‌کند مشخص شده است. از این رو Procfile باید جوری نوشته شود که حاوی دستورالعمل اجرای خودکار پروژه باشد. همچنین Procfile به نوعی نقش فایل کانفیگ را نیز بازی می‌کند چراکه سکوی ابری به کمک Procfile می‌تواند اپلیکیشن را به طور خودکار اجرا کند.در واقع Procfile به سکوی ابری اعلام می‌کند و می‌فهماند که باید چه کامندی را برای اجرای خودکار اپلیکیشن استفاده کند. به عبارت دیگر Procfile باعث می‌شود که سکوی ابری تشخیص دهد و بفهمد که چطور می‌تواند اپلیکیشن و پروژه را اتوماتیک استارت کند. برای اینکه ساختار و معماری یک پروژه را متوجه شوید تنها کافی هست که به Procfile آن نگاه بیاندازید. چراکه به ازای هر خط در Procfile یک proccess ای که قرار است توسط اپلیکیشن انجام شود که دستوری که آن را اجرا می کند وجود دارد.آشنایی با نحوه‌ی ایجاد Procfile و نوشتن آنفایل Procfile به صورت case sensitive هست و در صورتی که نام فایل و محتویات آن درست نوشته نشده باشد توسط سکوی ابری شناسایی نمی‌شود. اینکه محتوای Procfile پروژه شما چه چیزی باشد بستگی به این دارد که چه سرویسی در پروژه پیاده‌سازی شده است و برای اینکه بتوانید یک Procfile درست در Repository خود داشته باشید یا باید با اتکا به سواد developer ای خودتان فایل را بر اساس Syntax و قالب استاندارد آن بنویسید و یا به نحوی از نمونه Procfile پروژه های مشابه الگو برداری کنید.همنطور که پیش‌تر اشاره شد، هر خط از Procfile یک نوع proccess ای که قرار است اجرا شود را تعیین می‌کند و در مقابل آن نیز کامند مورد نیاز برای اجرای آن قرار داده شده است.: از این رو ابتدا به بررسی یکی از رایج‌ترین نوع proccess type در Procfile می‌رویم که به نوعی process type پیش‌فرض هست و در اکثر پروژه‌ها به کار برده می‌شوند.- معرفی proccess type نوع webزمانی که از عبارت web در قسمت proccess name استفاده می‌شود به این معنی هست که بخشی از اپلیکیشن و پروژه قرار است از HTTP استفاده کند و با ترافیک وب کار خواهد کرد. از این رو سکوی ابری در این خط از Procfile با خواندن کامندی که در مقابل عبارت web قرار دارد این سرویس را اجرا می‌کند و متوجه می‌شود که process model این اپلیکیشن با Web Server و ریکوست‌های HTTP سروکار دارد و . به عبارت دیگر اگر اپلیکیشن و پروژه شما شامل Web Server هم می‌شود باید در یک لاین از Procfile خود در مقابل عبارت web ، دستور و Startup Command ای که برای اجرای این سرویس نیاز هست را تایپ کنید. حال اینکه آن دستور چه چیزی باشد بستگی به کد برنامه، زبان برنامه نویسی و نوع سرویس استفاده شده دارد.به عنوان مثال در تصویر زیر مربوط به Procfile اپلیکیشنی هست که از Django و Gunicorn استفاده می‌کند:اما به جز web باقی process type ها عنوان process name اختیاری دارند و میتوان به صورت دلخواه نام process هر چیزی باشد ولی بهتر است مرتبط با process و دستوری باشد که در آن لاین از Procfile قرار است اجرا شود. (مثل worker ، clock و ... )

تهیه Incremental Backup به کمک Bash Script در لینوکس

حامد خاکباز — Sun, 28 Aug 2022 12:58:00 +0430

همواره یکی از مهمترین چالش ها در بحث Data Management ، فرآیند Backup یا پشتیبانگیری از داده ها است. از این رو باید به دنبال تکنیک های سریعتر و به صرفه تری (از حیث مصرف منابعی مانند دیسک و شبکه) در فرآیند Backup گیری بود. یکی از این تکنیک ها، Backup گیری به روش Incremental هست که باعث میشود هر بار تنها از تغییرات Backup تهیه شود. به عبارت دیگر به وسیله Incremental Backup در هر نوبت Backup گیری، بر خلاف نوبت اول از تمامی فایل ها و داده ها مجدد Backup تهیه نمی شود بلکه تنها از فایل های جدید و یا داده های تغییر یافته نسخه ی جدید Backup تهیه میشود. این کار در سیستم عامل های نسخه ی لینوکس میتواند با اجرا شدن یک Bash Script انجام شود.تهیه Incremental Backup به کمک Bash Script در لینوکسهمانطور که پیشتر اشاره شد در توزیع های مختلف سیستم عامل لینوکس به کمک Bash Script میتوان یک Directory را به عنوان مبدا برای Backup گیری و همچنین Directory دیگری را به عنوان مقصد برای ذخیره سازی فایل های Backup مشخص کرد تا هر بار که Script اجرا شد محتوای مبدا و مقصد با هم مقایسه شود و از هر داده جدیدی که در مبدا اضافه شده Backup گرفته شود. در این حالت Directory مبدا حاوی داده های موجود بر روی آن سیستم است و Directory مقصد در واقع یک فضای ذخیره سازی خارجی mount شده به آن سیستم است. برای این کار ابتدا یک فایل script با پسوند .sh ایجاد میکنیم، سپس مطابق تصویر زیر سطح دسترسی این فایل را طوری تعیین میکنیم که فایل همیشه با سطح دسترسی کامل و بهوسیله قابلیت Special Permissions همیشه با سطح دسترسی کاربر root اجرا شود: سپس فایل script را با vi باز کرده و مطابق تصویر زیر کد script را نوشته و ذخیره کنید: (مسیر src به معنای محل ذخیره داده اصلی و مسیر dst به معنای محل ذخیره سازی Backup است)در Script فوق از دو متغیر src و dst استفاده شده (که میتواند برای هر سناریو مسیری متفاوت داشته باشد) سپس محتوای موجود در src با dst بررسی می شود و بعد از هر بار اجرا شدن کد در صورتی که تغییرات جدیدی در src رخ داده باشد به صورت Incemental در dst کپی خواهد شد.

کاربرد EC چیست؟ بررسی مفهوم Erasure Code در Storage ها

حامد خاکباز — Sun, 28 Aug 2022 12:53:02 +0430

منظور از EC در Storage چیست؟ Erasure Code چیست؟ Erasure Coding چه کاربردی دارد؟ در این مقاله به معرفی و بررسیErasure-Code در ذخیره سازی خواهیم پرداخت. همچنین پیشنیاز این مقاله آشنایی با مفاهیمی از قبیل RAID و Software Defined Storage است.همانطور که می دانید یکی از اجزای اصلی هر ذخیره سازی، تکنولوژی RAID آن است اما چه جایگزین های برای RAID در دیتاسنتر های بزرگ وجود دارد؟ به خصوص در دیتاسنترهای بزرگ که حجم بسیار زیادی در حال ذخیره سازی است، همواره این سوال پیش می آید که آیا استراتژی جایگزین دیگری نیز وجود دارد که کمتر از RAID فضا بخواهد و از طرفی هم بتواند به اندازه یRAID از دیتا محافظت کند؟ در این مقاله با بررسی مفهوم Erasure Coding به این چالش پاسخ خواهیم داد.ذخیره ساز ها و Data Storage ها برای ایجاد reliability و data availability از تکنیک های زیادی استفاده می کنند که مطرح ترین آنهاRAID و Replication است. اما در این مقاله می خواهیم از تکنیک دیگری با عنوانerasure coding نام ببریم که همانندRAID و Replication مزایا و معایبی دارد که به بررسی آنها خواهیم پرداخت.زمانی که از erasure code صحبت می کنیم برای درک جایگاه آن باید در نظر داشت که درون یک کلاستر ذخیره سازی؛ Pool type یک ذخیره ساز می تواند یا RAID ، یا Replication و یا Erasure-Coding باشد. به عبارت دیگر erasure coding یک سازوکار جدید برای ایجاد data protection در ذخیره سازی است. از erasure coding به اختصار با عنوان EC و همچنین ECS نیز نام برده می شود.اما erasure code چه هدفی را دنبال می کند؟ و به کدام نیاز پاسخ می دهد؟ همانطور که عنوان شد؛ امروزه ذخیره سازها و بخصوص SDS های نوین سرشار از قابلیت های فراوانی هستند که یکی از آن ها erasure coding است. بدین ترتیب کهSDS ها در ساختار خود جهت لحاظ کردن data reliability به جای استفاده ازRAID و Replication ، از قابلیت و تکنیک دیگری به نام erasure coding هم می توانند استفاده کنند و می توانPool type یک استوریج راerasure coding گذاشت.هدف اصلی erasure coding مقابله و جلوگیری از data loss است و تضمین می کند که اگر همزمان چندین دیسک از بین برود باز هم دیتا را از دست نمی دهد. همچنین در مقایسه با Replication و RAID بسته به نوع سناریو، این قابلیت می تواند rebuild time کمتری در هنگام ریکاوری داشته باشد.از طرفی همانطور که می دانیم در دنیای امروزی یک ذخیره ساز سوای اینکه از کدام تکنیک استفاده می کند باید نشان دهد که می تواند بعد از یک Failure باز هم امکان و توان دسترسی به دیتا را ادامه داده و در اصطلاح continuity و availability داشته باشد.اما availability چطور در erasure coding ایجاد می شود؟ به عنوان مثال در RAID از دیسک های دیگری برای ایجاد data availability استفاده می شود و یا در Replication از Replica استفاده می شود ولی در erasure coding از erasure-code ها استفاده می شود. در حقیقت erasure coding نقطه ی مقابل Replication یا RAID است یعنی یک Storage Pool برای ایجاد reliability و همچنین Data Availability می تواند به جای RAID و Replication از erasure coding استفاده کند.همچنین شایان ذکر است که درون یکStorage Cluster می توان هر دو نوع تکنیک را در Pool های جداگانه در یکCluster داشت، البته این موضوع باید توسط نرم افزار ذخیره سازی پشتیبانی بشود.اما چه زمانی باید ازerasure-coding استفاده کرد؟ و چه زمانی کاربرد دارد؟ یکی از کاربردهای erasure code زمانی است که می خواهیم از یک استوریج برای آرشیو فایل استفاده کنیم، در این حالت به صرفه نیست که از RAID یا Replication استفاده کنیم چراکه به دنبال سرعت بالای خواندن و نوشتن نیستیم و هدف این است که حجم زیادی از داده را در فضای کمتری جای بدهیم.یکی دیگر از کاربردهای مهمerasure coding در Cloud Storage ها، Object Storage ها و فضاهای ابری مثل Amazon S3 است که در بطن خود برای ذخیره سازی از این تکنیک استفاده می کنند. چراکه بدین ترتیب می توانند هم مصرف دیسک را تا 40 درصد کاهش دهند و هم تا نزدیک به 99.999999 درصد durability و دوام پس از Disaster داشته باشند. همچنین Software Defined Storage ها و همچنین Hyper-converged Storage های زیادی از erasure coding استفاده می کنند که از مطرح ترین آنها می توان بهVxRail ، VMware vSAN و CEPH اشاره کرد.برای مثال؛ VMware vSAN از erasure coding برای ایجاد availability در سناریو All Flash خود پشتیبانی می کند، همچنین Ceph نیز از erasure coding پشتیبانی می کند و به هنگام ساخت یک Pool در Ceph می توان تعیین کرد که آیا این Pool از erasure coding استفاده بکند یا خیر. ولی باید در نظر داشت که در هیچ ذخیره سازی نمی توان بر روی یک Pool واحد همزمان از erasure coding در کنار RAID و یا Replication استفاده کرد.اما سازوکار این تکنیک به چه شکل است؟ در حقیقت erasure coding دیتا را به chunk ها و تیکه های کوچکی خرد کرده سپس chunk ها و تیکه های کوچک را encode کرده و در نقاط پراکنده ای از Pool (طبق الگوریتمی که availability را تضمن کند) ذخیره می کند. همین مکانیسم کاری erasure coding باعث شده که Storage Pool هایی که از erasure coding استفاده می کنند فضای ذخیره سازی کمتری مصرف کنند. یعنی erasure coding به نسبت RAID و Replication دیسک کمتری نیاز دارد. به عنوان مثال erasure coding به اندازه RAID1 برای داده Protection ایجاد می کند ولی در مقایسه با RAID1 فضا و storage capacity کمتری نیاز دارد. چراکه erasure coding الگوریتم محاسباتی ای دارد که می تواند سایز اصلی دیتا را از یک سایز کوچک شده، ریکاور و regenerate کند. اما یکی از معایب این راهکار این است که؛ erasure coding باعث می شود که ذخیره ساز نیاز به CPU و پردازشگر بسیار قوی تری داشته باشد چرا که محاسباتی که باعث کاهش حجم ذخیره سازی می شود بار پردازشی زیادی ایجاد می کند. به عبارت دیگر Erasure coding یا EC یک فرآیند CPU-intensive است که در مواقع Disaster و در حین فرآیند ریکاوری باعث می شود دیتای corrupt شده از نو محاسبه شده و مجدد احیا شود.به همین دلیل استفاده از erasure coding بیشتر در مواقعی توصیه می شود که یک حجم بسیار زیادی از دیتا را می خواهیم ذخیره کنیم و به جای اینکه دغدغه Performance I/O داشته باشیم دغدغه ی اول و ارجح تر، کم کردن حجم و تعداد دیسک مصرفی است. به عنوان نمونه زمانی که قصد جای دادن چند Petabyte دیتا را داریم (به عنوان مثال برای 4 PB ) اگر از مکانیسمی غیر از erasure coding استفاده کنیم برای تامین Availability و Data Protection باید حداقل 2 برابر آن فضا مصرف کنیم ( باید 8 PB فضا در نظر بگیریم ) ولی زمانی که از erasure coding استفاده می کنیم هرچند سرعت I/O آهسته و کندتر می شودولی دیگردر محاسبه فضا، همه چیز ضربدر دو نمی شود و (برای داده های غیر I/O Intensive) در مجموع TCO بهتری بدست می آید ، چرا که برآورد می شود erasure coding تا چهل درصد هزینه را کاهش می دهد. همچنین erasure coding تضمین می کند که Data های موجود را پس از خرد کردن تحت قالب Data Chunk های کوچک شده در Failure Zone های جداگانه ای از Pool ذخیره می کنند.محاسبات ریاضی erasure coding به نحوی است که یک دیتا پس ازذخیره شدن در Pool به پنج بخش پراکنده تقسیم شده است که این پنج بخش در مجموع و روی هم رفته فضایی کمتر از دو برابر دیتای اصلی مصرف می کنند و از طرفی اگر Disaster ای رخ بدهد استوریج می تواند از دست دادن حداکثر تا دو بخش را تحمل کند و به هنگام ریکاوری erasure coding می تواند با دسترسی به حداقل سه بخش باقی مانده، کل دیتای اصلی را ریکاور کند. همچنین به عنوان نکته ی آخر باید در نظر داشت که erasure coding به معنای compression نیست و باهم تفاوت دارند.

ژورنالینگ ( Journaling ) چیست؟ بررسی مفهوم Journaling فایل سیستم

حامد خاکباز — Sun, 28 Aug 2022 12:48:57 +0430

منظور از Journaling در فایل سیستم چیست؟ Journal در Database چیست؟ Journal چه خصوصیاتی دارد؟ چه تفاوتی بین Journaling در Database و Journaling در File System وجود دارد؟ در این مقاله به تحلیل و بررسی Journaling در مفاهیم فایل سیستم و بحث دیتا خواهیم پرداخت و ویژگی های آن را بررسی و تحلیل خواهیم کرد.اگر با SQL و مباحث Database آشنایی دارید و یا اگر با فایل سیستم های XFS ، ZFS و یاext3,4 کار کرده اید تا به حال با اصطلاح Journal برخورد داشته اید. هدف اصلی Journal چه درDatabase و چه در File System این است که در هنگام Disaster از خراب شدن ساختار داده و خود داده جلوگیری کند و این نقطه مشترک مفهوم Journaling در Database و File System است. اما در این مقاله ابتدا به بررسی این مفهوم در فایل سیستم پرداخته و سپس آن را در دیتابیس نیز بررسی می کنیم.بررسی مفهوم File System Journalingیک Journaling Filesystem در حقیقت فایل سیستمی است که؛ ورودی هایی که هنوز به شکل کامل در قسمت اصلی دیسک ذخیره نشده اند را زیر نظر می گیرد، ازData Structure آنها برای خودشMetadata و Log بر می دارد و در محلی به عنوان Journal ذخیره می کند تا جلوی corrupt شدن اطلاعات موجود در فایل سیستم را بگیرد. به عبارت دیگر یک Journaling Filesystem پیش از ذخیره کردن اصل تغییرات به صورت Random، یک Log Record به صورت Sequential می نویسد که این Log Record به شکلی کامل اصل تغییرات را تشریح می کند.قابلیت Journaling همانند fsck نیست ، بلکه به نوعی جایگزین آن شده است؛ در فایل سیستم هایی که قابلیت Journaling را ندارند (به عنوان مثال) به هنگام Power Loss زمانی که مجدد اقدام بهboot سیستم عامل خود می کنید بایدCheck Utility بر رویFile System اجرا شود که فرآیندی زمانبر است و ممکن است بی نتیجه باشد. اما زمانی که قابلیت Journaling در فایل سیستم موجود باشد سیستم ابتدا اقدام به خواندنMetadata موجود درFilesystem کرده و از طریقLog هایی که درون قسمتJournaling ذخیره شده در زمان کوتاهی اقدام به تعمیر ساختار دیتای موجود در فایل سیستم کرده و کمک می کند تا دیتا به وضعیت پایدار خود باز گردد. همچنین باید در نظر داشت که Journaling به معنای Redundancy نیست. در واقع Journaling باعث می شود که یک فایل سیستم Recover-able باشد. Journal در فایل سیستم یک بخش جداگانه ولی مرتبط با بخش اصلی دیسک است که عملیات نوشتن بر روی دیسک را کارآمدتر می کند. همچنین Journaling باعث می شوند که I/O های Random پیش از نوشته شدن روی دیسک به Sequential تبدیل شوند.اما هم اکنون به چالش ها و نیاز هایی که پیش از Journaling در دنیایFile System وجود داشته و مطرح بوده نگاهی کوتاه کنیم؛ موارد و انتظاراتی که به مرور زمان از File System ها می رفته مثل نیاز به داشتن پارتیشن هایی با اندازه بزرگ روی سرور، لزوم ریکاوری سریع پس از Crash یا Power Loss ، افزایش I/O و ... که همه ی این نیازها لزوم ایجاد تکنیک های جدیدی را می طلبید که بتواند این دغدغه ها را پوشش دهد.در همین زمان فایل سیستم هایی از قبیل XFS و ext3 با مطرح کردن ویژگی هایی مثل Journaling سعی در برطرف کردن این چالش ها کردند. چرا کهJournal در واقع یکLog mode در فایل سیستم است که دیتا به هنگام ذخیره سازی ابتدا بر روی آن قرار می گیرد و سپس در محل اصلی خود ذخیره می شود تا از بروز Delay به هنگامWrite جلوگیری کند. برای مثال زمانی که یک دیسک با فایل سیستم XFS فرمت بشود به دو Partition با نام های data و همچنین journal تقسیم می شود. در نظر داشته باشید که Journaling File System بعد از اینکه دیتا وارد فایل سیستم می شود عملیات Journaling را زمانی انجام می دهد که بخواهد دیتا را بر روی دیسک ها بنویسد. Journal در لبه ی دیسک قرار دارد و وجود این مکانیسم باعث افزایش Performance در مواردی از قبیلrandom write می شود.مفهوم Journaling در Cephاما نرم افزار های ذخیره سازی ای نیز هستند که از قابلیت Journaling استفاده می کند و Journaling در سطح نرم افزار ذخیره سازی با Journaling File System نباید اشتباه گرفته شود. یکی از این نرم افزار های Ceph است. نرم افزارCeph به عنوان یک Software Defined Storage ای که Open Source است به صورت یک مجموعه راهکار قابلیت های فراوانی دارد که یکی از آنها Journaling است. بینCeph journaling و مفهوم filesystem journaling تفاوت بسیاری وجود دارد. کلاستر Ceph پیش از اینکه دیتا را بخواهد به فایل سیستم بدهد عملیات Journaling را قبل از دادن دیتا به فایل سیستم انجام می دهد ولیJournaling File System گام بعدی و یک لایه پایین تر است و زمانی که دیتا را می خواهد بر روی دیسک فیزیکی بنویسد عملیاتJournaling در فایل سیستم انجام می شود.از این رو در کلاسترCeph از Journaling File System استفاده نمی شود چرا که باعث می شود یک دیتا دوبار نوشته شود و Overhead ایجاد می کند. دقت کنید که اینجا Ceph یک فایل سیستم نیست بلکه یک SDS و یک نرم افزار ذخیره سازی است که بدون هیچ ارتباطی با فایل سیستم از قابلیت و مفهوم Journaling استفاده می کند. زمانی که در Ceph از Journaling استفاده می کنیم می توان Journal Part را بر روی یک دیسک مجزا قرار داد. یعنی اگر یک هارد دیسکHDD داریم می توانیم تعریف کنیم که Journal این هارد بر روی یک دیسک SSD مجزا قرار بگیرد. همچنین می توان Journal های چند دیسک اصلی را بر روی یک SSD واحد قرار داد یعنی یکSSD را به چند پارتیشن تقسیم کرده و درون هر پارتیشن مجزای آن Journal File مخصوص دیسک دیگری را جای داد. در این مورد نسبت 1 به 4 توصیه می شود یعنی به ازای 4 عدد دیسک HDD می تواند یک SSD را مدنظر گرفت و Journal های آن چهار عدد HDD را روی آن ذخیره کرد. این موضوع باعث افزایشThroughput شده، میزانCPU Wait یا access time را کاهش داده و در عین حال باعث کاهش write Latency هم می شود. همچنین این موضوع می تواند منجر به کاهش هزینه کلاستر ذخیره سازی نیز بشود چرا که به جای اینکه تمام دیسک های ذخیره سازی را از جنس SSD تهیه کنیم می توانیم در تنها از چند دیسک SSD استفاده کنیم و سایر دیسک ها همان HDD باقی بماند. اما یکی از معایبش آن است که اگر دیسک مجزای Journal ازبین برود ممکن است تمام دیتاهای موجود بر روی دیسک های اصلی نیز دچار آسیب می شوند. به همین دلیل در مواقعی که Journal را در دیسک مجزا قرار می دهند برای آن دیسک مجزا یکRAID 1 نیز در نظر میگیرند. همچنین در کلاستر Ceph اگر دیسک های اصلی خودشان SSD باشند با همین تناسب می توان به ازای 18 عدد SSD یک عدد NVMe در نظر گرفت و Journal های 18 عددSSD را بر روی یک NVMe ذخیره کرد. از این رو به طور معمول در کلاستر هایCeph که در سطح نرم افزار ذخیره سازی Journaling فعال است؛ دیگر در لایه فایل سیستم از فایل سیستمی استفاده می کنند که Journaling در آن به صورت پیشفرض فعال نباشد و یا بتوان Journaling File System را غیرفعال کرد چرا که منجر به دوباره کاری و ایجاد بار اضافه می شود.اما باید در نظر داشت کهJournaling با Caching در Storage متفاوت است چرا که در Caching با هدف افزایش سرعت اصل دیتا در Caching Tier ذخیره می شود ولی در Journaling با هدف حفاظت از اصل دیتا یک سری Log و Metadata ذخیره می شود که می توان از آن به دیتای اصلی رسید. همچنین Journaling به معنایintent log نیست بلکه خود یک نوعی از intent log هست و برخی قابلیت های آن بسته به فایل سیستمی که Journaling را ارایه می کند تفاوت دارد.بررسی مفهوم Database Journalingاما بعد از بیان تفاوتCeph Journaling با مفهوم filesystem journaling هم اکنون به بیان تفاوتی دیگر می پردازیم؛ باید در نظر داشت که Journaling در فایل سیستم با Journaling در Database هم تفاوت دارد و یکی بودن اصطلاح آنها و همچنین شباهت سازوکارشان نباید باعث جابجا در نظر گرفتن آنها شود.فایل سیستمی که قابلیتJournaling دارد باعث می شود که دیتای ذخیره شده در دیسک بعد از یک آسیب بتواند زودتر به ثبات و پایداری برسد اما این موضوع تنها در سطح دیسک است و یک Journal File System نمی تواند آسیب هایی که به ساختار اپلیکیشن وارد شده را برطرف کند. به عبارت دیگر بعد از تعمیراتی که توسط Journal در دیسک انجام می شود باز هم از دید اپلیکیشن خطا هایی در درون Database دیده می شود و باز هم فایل دیتابیس corrupt است.منظور از Journaling در Database شبیه DB Transaction Log است و با آنچه که در فایل سیستم هست تفاوت هایی دارد. DB Journaling باعث می شود که اگر در هنگام اعمال تغییر و یا ذخیره داده ای در دیتابیس خللی ایجاد شود (برق سیستم قطع بشود و یا اپلیکیشن کرش کند) داده ای که تا نصفه ذخیره شده از بین نرود و ساختار پایگاه داده به هم نریزد. یعنی DB Journaling لزوم نوشته شدن کامل داده در دیتابیس را از بین می برد و(ضمن ایجاد بازدهی وPerformance بیشتر) تضمین می کند که تمام داده ها و تغییرات را تحت نظر داشته و بعد از یکDisaster می تواند به ریکاوری یک دیتابیس از بین رفته کمک کند.به عبارت دیگر به جای این که تراکنش ها و Update ها (به صورت Random ) از همان ابتدا مستقیم درون دیتابیس ذخیره شوند، DB Journaling باعث می شود از داده Log هایی درون Journal File (به صورت Sequential ) جای داده شوند تا امکان rollback بعد از یک Disaster وجود داشته باشد. در واقع Database Journal File نقطه مقابل همان Database Core Data File است، و باعث می شود تا یک transaction log ابتدا در Journal ذخیره شده و سپس سر فرصت دیتا به Core Data File ها یا محل اصلی شان منتقل می شوند.اما در متن فوق اشاره کردیم کهDatabase Journaling باعث افزایشPerformance نیزمی شود، ولی چگونه؟ تصور کنید زمانی را که یک Database قابلیت Journaling را نداشت در آن زمان اگر تراکنشی می بایست بر روی دیتابیس انجام می شد باید تغییرات در نهایت به صورت کامل درون Database ذخیره می شد و ذخیره در Database از جنس Random است به صورت Random Write انجام می شود و باعث ایجاد بار سنگینی بر روی دیسک می شود. ولی زمانی که Journaling فعال باشدTransaction Log هایی از تراکنش ها و تغییرات دیتابیس به صورت Sequential Write و به شکل موقت درون Journal File ذخیره می شود و از آنجایی که Sequential بار سبک تری نسبت به Random دارد در لحظه لود کلی و میزان تاخیر کاهش یافته و بازدهی (سرویسی که از آن دیتابیس استفاده می کند) افزایش می یابد.

SDS چیست؟ بررسی مفهوم Sofware Defined Storage

حامد خاکباز — Sun, 28 Aug 2022 12:40:14 +0430

منظور از SDS یا Software Defined Storage چیست؟ مفهوم SDS چه کاربردی دارد؟ SDS چه معایبی دارد؟ اگر با مفاهیم ذخیره سازی و زیرساخت Storage آشنا هستید تاکنون با عنوان SDS برخورد کرده اید. در این مجموعه مطالب از زوایای جدیدی به تعریف کاربردی و بررسی اولیه و تحلیل Software Defined Storage و در مقاله های بعدی به بررسی انواع SDS خواهیم پرداخت. همچنین پیش نیاز این مطالب آشنایی با مفاهیمی از قبیل Storage Virtualization و دوره +Storage است.معرفی مفهوم SDSیکی از مهمترین چالش هایی که در ذخیره سازی یا Storage وجود دارد، رشد تدریجی میزان دیتا ذخیره شده و به تبع آن نیاز به افزایش ظرفیت ذخیره سازی است. در یک سازمان بزرگ بسته به نوع کسب و کار میتوان سالیانه 40 تا 60 درصد انتظار افزایش میزان دیتا را شاهد بود و بدنبال آن باید ظرفیت ذخیره سازی Data Storage آن سازمان نیز به همین میزان توان افزایش را داشته باشد. یکی از سوالاتی که در این لحظه مطرح می شود سوال در مورد آینده ذخیره سازی است؛ تا کی و چقدر دیتا افزایش می یابد؟ یا به عبارت دیگر تکنیک ها و تکنولوژِی های ذخیره سازی کنونی تا چه زمان پاسخگوی نیازها هست و چقدر هزینه اقتصادی دارد.به همین دلایل در طول تاریخ IT و با تغییرات هر دوره شاهد ایجاد روش های جدید ذخیره سازی هستیم و همیشه باید به دنبال راهکاری باشیم که نیازهای دوره های بعد از خود را نیز بتواند پوشش دهد. هم اکنون آخر خط و بهترین مجموعه تکنیک راهکار ذخیره سازی، Software Defined Storage یا SDS است چرا که SDS به شرکت ها کمک می کند تا انعطاف پذیری کافی در مقابله با روندهای نوین و گرایش های جدید دنیای دیجیتال را داشته باشند و مشکلات Critical ذخیره سازی را برطرف کنند.همانطور که همه ی ما بارها شنیده ایم؛ تعریف های زیادی از زوایای مختلف از مفهوم Software Defined Storage شده است، اما آنچه که باید در بحث تئوریک SDS مطرح شود این است که SDS دروازه ورود Hardware به دنیای AI ، HPC و Big Data است و منظور از واژه Software در عبارت Software Defined Storage و در این مفهوم به معنای نقطه ی مقابل Hardware نیست و نمی توان استوریج را به دو بخش سخت افزاری و نرم افزاری تفکیک کرد، چرا که SDS بر خلاف تصور اولیه به معنای رها شدن و یا مستقل بودن از سخت افزار نیست.بلکه منظور از Software در این عبارت به معنای رها شدن از Hardware Vendor و مستقل بودن از سازنده ی سخت افزار و ویژگی های خاص هر سخت افزار است. به همین دلیل است که SDS مورد توجه سازمان ها و مدیران قرار می گیرد چرا که می توان ظرفیت آن را به سادگی افزایش داد بدون اینکه وابسته به سخت افزار و یا سازنده خاصی باشیم و این منجربه کاهش هزینه نگه داری و یا TCO می شود چرا که SDS در بطن خود نوعی Cost Saving را به دنبال دارد.یک SDS نحوه عملکرد Storage I/O را برای گرفتن Performance بیشتر از منابع ذخیره سازی موجود تغییر می دهد و باعث افزایش efficiency در مصرف ظرفیت ذخیره سازی ، storage provisioning و همچنین فرآیند های snapshot/clone در سطح Storage Operating System می شود. یک SDS یک Hypervisor نیست اما مانند یک Hypervisor ، عملکرد و انعطاف پذیری را برای استفاده بهتر از منابع ذخیره سازی افزایش می دهد.همچنین پیش از اشاره بیشتر به مزایای SDS برای درک بهتر اهداف SDS از معایب آن نیز مواردی را به زبان می آوریم از این رو در اینجا و به طور مختصر از معایب SDS می توان به ایجاد Complexity اشاره کرد و علاوه بر آن ضرورت نیاز هرچه بیشتر به نیروی متخصص .از طرفی برخی راهکار های ذخیره سازی هستند که با وجود اینکه در طراحی اولیه تابع مدل SDS هستند ولی بازهم وابستگی به سخت افزار یا Vendor خاصی دارند. از طرفی در کنار تمام خصوصیات خوب SDS که جلوتر به آنها بیشتراشاره میکنیم؛ سازمان های کوچک و متوسط زیادی هستند که به سمت SDS رفته اند ولی هزینه های زیادی را متحمل شده اند و دست آخر با نارضایتی تصمیم به جایگزینی Storage خود و استفاده از راهکاری غیر از SDS شده اند. علت چیست؟ چرا SDS پاسخگو نبود؟ چرا نشد؟بسته به شرایط مختلف دلایل غیرفنی و فنی زیادی می تواند داشته باشد اما یکی از شایع ترین آنها تعریف سازوکار SDS در موقعیتی است که اهداف واقعی تئوری SDS را پوشش نمی دهد. تئوری SDS برای ذخیره سازی یک هدف اصلی و اساسی را دنبال می کند و آن این است که (بدون کاهش سرعت و پرفرمنس ذخیره سازی ، بدون صرف هزینه بدون توجیه اقتصادی و بدون کاهش پایداری و سلامت دیتای ذخیره شده)، امکان تدریجی افزایش ظرفیت زخیره سازی از یک bit تا Zettabyte و یا Yottabyte را فراهم کند و این تناسب باید رعایت و اندازه گیری شود.مفهوم SDS باعث می شود سازمان های Enterprise و همچنین Cloud Provider ها بتوانند برای زیرساخت خود یک Shared Storage ایجاد کرده و منابع ذخیره سازی خود را توزیع کنند. در واقع کاربرد اصلی و عمده SDS در Storage های زیرساخت های Public Cloud است. چرا که بدون SDS نمی توان در اندازه ها و ظرفیت بالای ذخیره سازی سرویس دهی کرد چون راهکاری به غیر از SDS در Cloud Provider می تواند هزینه های نگه داری بسیار سنگینی را ایجاد کند که توجیه اقتصادی ندارد.از طرفی یک SDS باید Open Source باشد تا بتواند به کمک یک Community خودش را رشد داده و به بلوغ برسد تا ویژگی های آن بر اساس نیاز هر بیزینس قابل Customize و انعطاف پذیر باشد. به عبارتی دیگر Storage مورد استفاده در زیرساخت ابری باید all in one storage backend باشد و تنها SDS می تواند این دغدغه ها را پوشش دهد.زیرساخت های Cloud مبتنی بر SDS انعطاف پذیری مورد نیاز ارائه دهندگان خدمات ابری را برای ارایه راه حل های ذخیره سازی از قبیل Infrastructure as a Service (که نمی توان از دیگر راه های سنتی ذخیره سازی سازمانی به دست آورد) و یا هر نوع Storage as a Service را فراهم می کند تا قابل ذخیره سازی ابری قابل ارایه باشد زیرا در حقیقت اساس SDS برای تحقق آنها طراحی شده است. بدین ترتیب با استفاده از SDS ، ارائه دهندگان خدمات ابری می توانند فضای ذخیره سازی ابری کم هزینه و قابل اطمینان را به مشترکین خود ارایه دهند.اما همانطور که گفته شد سازوکار SDS از معماری های ذخیره سازی سنتی پیروی نمی کند. در واقع با پیدایش مفهوم SDS معماری ذخیره سازی نیز بر اساس محدودیت هایی که SDS از بین برد، دوباره و از نو طراحی و نوشته شده است. وقتی که می گوییم SDS مقیاس پذیر است یعنی الگوریتم های آن مقیاس پذیر شده است. به عبارت دیگر SDS به دنبال استفاده از الگوریتم هایی است که Scalable Hashing داشته باشند و بتوانند روند ذخیره دیتای تحت کنترل خود را با این نوع محاسبات جفت و جور کنند.هم اکنون می توان از مفهومی تحت عنوان decentralized cluster در SDS صحبت کرد که به معنای جای دادن دیتا به صورت غیر متمرکز است. یعنی برخی الگوریتم های مورد استفاده در SDS در هر تراکنش به جای استفاده از یک Metadata Table واحد ای که از پیش تعریف شده ، فرآیند محاسبه و تعیین محل قرار گیری هر دیتا را در همان لحظه و هر بار بر روی Node های مختلفی انجام می دهند. این موضوع سرعت جستجو برای یافتن محل قرارگیری هر دیتا را به طرز چشمگیری افزایش می دهد. البته باید در نظر داشت که همه راهکارهای SDS موجود از این ویژگی ها پشتیبانی نمی کنند.

ZFS چیست؟ معرفی و آشنایی با فایل سیستم Zettabyte File System

حامد خاکباز — Sun, 28 Aug 2022 12:37:00 +0430

منظور از فایل سیستم ZFS چیست؟ فایل سیستمZFS چه کاربردی دارد؟ اگر به مفاهیم ذخیره سازی علاقه مند هستید این سلسله مطالب را مطالعه کنید. در این سری مطالب به معرفی کاربردی و بررسی اولیه و تحلیل این File System خواهیم پرداخت. در نظر داشته باشید که هرآنچه در این مطلب بیان می شود تنها معرفی مفاهیم و قابلیت های ZFS هست و بسیاری از کاربردهای آن در مطالب بعدی پوشش داده می شود. همچنین پیش نیاز این مطالب آشنایی با مفاهیمی از قبیل Software Defined Storage و Storage Virtualization است.فایل سیستم ZFS چیست؟ممکن است در هنگام نصب سیستم عامل هایی از قبیل Ubuntu ، Debian و ... گزینه انتخاب فایل سیستم ZFS را دیده باشید و یا اگر با FreeNAS یا Oracle Storage آشنایی دارید اسم این فایل سیستم را شنیده اید. عبارتZFS مخفف Zettabyte File System و تلفظ اصلی آن ZFS ((زیفس)) است. این فایل سیستم توسط فردی به نام Matthew Ahrens و چند نفر دیگر ساخته شده است.که برای اولین بار و در ابتدا برای سیستم‌عامل Solaris طراحی شده است. ZFS در آغاز کار خود Open Source نبود ولی پس از چند سال با مطرح شدن عنوان OpenZFS پا به دنیای Community گذاشت و هم اکنون Source Code های آن بر روی github قابل مشاهده و دانلود است.نکته ای که در خصوص ایدهZFS جالب است این است که دید و انتظارات شما را در خصوص یک فایل سیستم تغییر می دهد چراکه ZFS ترکیبی از خصوصیات File System و Volume Manager است و یک مجموعه دیسک را دربرمی گیرد. به عبارت دیگر ZFS یک Volume Manager منطقی و Logically است و یک Virtualized Storage را مدیریت کرده و توسعه می دهد.از کاربرد های این فایل سیستم می توان به پشتیبانی از میزان فضای بسیارزیاد ذخیره سازی اشاره کرد. این فایل سیستم قابلیت مقیاس پذیری بالایی دارد به شکلی که می توان حجم فضا پوشش داده توسط آن را تا مقادیر Zettabyte افزایش و ارتقا داد. فایل سیستم ZFS دیتا را ایمن نگه می دارد و با حذف کردن محدودیت های فایل سیستم های پیش از خود مدیریت دیتاها و دیسک ها را ساده می کند.با راهکار (ZFS) Zettabyte File System می توان یک Shared Storage به صورت Open source ارایه داد. به این معنا که اگر به دنبال یک راهکارOpen Source شده برای راه اندازی زیرساخت Storage خود هستید می توانید روی ZFS حساب کنید. اما باید در نظر داشته باشید که تنها یک تنظیم اشتباه کوچک می تواند شما را از درک بازدهی بالای آن محروم کند.فایل سیستم ZFS در لینوکس (یا به اصطلاح Co-Founder آن OpenZFS ) می تواند با LVM ترکیب شده و نیاز به RAID Controller و یا Smart Array را در یک کلاستر ذخیره سازی حذف کند. البته بدین شکل که از Compute Resource سیستم عامل خود برای تامین منابع پردازشی مورد نیاز فرآیند هایی از قبیلRAID بندی استفاده می کند. از این رو یکی از مشکلات شایع در یک کلاستر ذخیره سازی ZFS مشکل High Memory Usage یا مصرف بالای RAM بر روی Storage Node است که به عنوان یک hidden cost باید در نظر گرفته شود.برخی تصور می کنند که با ZFS یک RAID نرم افزاری بسته می شود اما در واقع RAID ای که در ZFS بسته می شود نرم افزاری و یا سخت افزاری نیست بلکه در سطح فایل سیستم و بر روی دیسک ها اتفاق می افتد.فایل سیستم ZFS قابلیت Extend کردن Storage Pool را دارد از این رو می توان به مرور زمان و با اضافه کردنDisk Group های جدید اندازه حجمPool ، Volume و حتی LUN خود را افزایش داد.به عبارتی مکانیسم افزایش فضا در Storage ای که رویZFS باشد بسیار ساده تر صورت می گیرد چرا که به عنوان مثال RAID1 در ZFS در سطح Disk Group نیز قابل مدیریت است و نیاز به Partition جدید نیست و بر روی همان Pool در هر زمانی قابل انجام است.اما ZFS نیز مانند سایر راهکار های ذخیره سازی مکانیسم هایی برای Caching دارد که می تواند ازDisk هایی به عنوانCache در یک Pool استفاده کند. ولی آنچه که ZFS را متمایز می کند وجود مواردی از قبیل ARC ، L2ARC SLog و ZIL است که در مطالب بعدی به توضیح مفصل هر کدام از این قابلیت ها خواهیم پرداخت که منجر به افزایش Perfomance ، کاهش Latency و همچنین حفاظت از داده ها می شوند.به عبارت دیگر ZFS با ترکیب کردن DRAM ، Flash و هارد دیسک و با کاهش Write/read Latency به دنبال ایجاد یک تعادل و بالانس نسبی میان بازدهی و هزینه است تا بتواند به TCO کمتری برسد. همچنینZFS با استفاده ترکیبی از این تکنیک های ذکر شده به دنبال کاهش نیاز به مانیتور مداوم Storage برای مدیریت و برطرف کردن I/O bottleneck است.قابلیت دیگری که توسطZFS ارایه می شوند پشتیبانی به طور خاص از الگوریتم های LZ4 ، LZJB و ... در فرآیندCompression است که دیتا اصلی را به یک نمونه مطابق با اصل ولی با حجم کمتر تبدیل می کند تا در حین ذخیره سازی باعث کاهش فضای اشغال شده بر روی دیسک شود.در یک کلاستر استوریج که باZFS راه اندازی شده است می توان به قابلیت replication در ZFS اشاره کرد که می تواند یک Replica را بر رویStorage Node دیگری ارسال وSync کند و بعد از یکDisaster از Storage Pool خود یک نسخه Backup را بازگردانی کند.اما یک قابلیت پیشرفته درZFS گرفتن Snapshot در سطح Storage است که می تواند به عنوان یک راهکار Offline Backup و به عنوان بخشی از یک business continuity plan در نظر گرفته شود چرا که ZFS در این ویژگی به کمک مدل Copy-on-Write در ساختار Transitionally خود می تواند به صورت ایزوله از تمام دیتا های تحت کنترل فایل سیستم (و یا تنها ازتغییرات آن نسبت به سری قبلی) Backup Point تهیه کند.فایل سیستم ZFS در مقیاس کوچک از نظر مدیریت بسیار ساده است، اما در مقیاس های بالا و در اندازه های بزرگ نیازمند طراحی های بسیار عمیق و دقیق دارد. از طرفی فایل سیستم ZFS به عنوان یک راهکارShared Storage تنها قابلیت ارایهBlock Storage را دارد و امکان ارایه Object و یاFile-Level را ندارد. همچنین قابلیت ها و یا باگ های فایل سیستم ZFS از طریق بروزرسانی Firmware آن تغییر یا گسترش می یابد اما گفته می شود که بر خلاف سایر راهکارهای مشابه قابلیت Downgrade کردن Firmware را ندارد.

سرویس Nova در OpenStack چیست؟ معرفی نووا در اوپن استک

حامد خاکباز — Sun, 28 Aug 2022 12:31:53 +0430

منظور از سرویس Nova در OpenStack چیست؟ کاربرد Nova در OpenStack چیست؟ چه امکاناتی در قالب سرویس Nova در محیط اوپن استک به ما ارائه می شود؟معرفی سرویس Nova در OpenStack قسمت 1 معرفیهدف از ارائه این سلسله مقالات؛ بررسی تئوری OpenStack Compute service با نام Nova و تحلیل قابلیت های آن می باشد. همچنین پیش نیاز این مباحث آشنایی اولیه با OpenStack ، درک مفاهیمی از قبیل مجازی سازی ، Cloud و Infrastructure as a Service می باشد.معرفی مجموعه سرویس Nova Compute در OpenStackمجموعه سرویس Nova یک ساز و کار مشخص برای کنترل پلتفرم IaaS ارائه می دهد، که برای متخصصان OpenStack امکان ارائه یک Virtual Machine با تنظیمات درخواستی را فراهم می کند. به عبارت دیگر مجموعه سرویس Nova باعث می شود که شما بتوانید ماشین های مجازی ساخته شده (توسط هاست های مجازی تان) را به عنوان یک کالا به مشتریانتان ارائه دهید.در حقیقت API های Nova مشخصات ماشین مجازی خواسته شده (ازقبیل میزان RAM ، CPU ، Disk ، Network و ..) را دریافت کرده و سپس از طریق تعامل با Hypervisor پس از ساخت آن ماشین، شرایط را برای ارائه به مشتریان فراهم می نماید.شایان ذکر است که Nova (به عنوان هسته اصلی یک سیستم IaaS ) خود با زبان برنامه نویسی Python نوشته شده است و Source Code آن بر روی اینترنت قابل روئیت می باشد.راهکار Nova Compute Service با اکثر Hypervisor های مطرح سازگار است، اما ممکن است هر Hypervisor برخی از قابلیت های آن را پشتیبانی نکند، کهCompatibility Matrix آن موجود است. اما بالاترین میزان سازگاری با Nova را KVM Hypervisor دارا می باشد و توصیه خود OpenStack هم استفاده از راهکار مجازی سازی KVM Linux می باشد. در ادامه با دو اصطلاح پرکاربرد درون مجموعه سرویس Nova آشنا خواهیم شد.منظور از Compute Node و Instance در OpenStack-Novaبه هر Hypervisor ای که در اختیار Nova باشد، اصطلاحا یک Compute Node گفته می شود. همچنین به هر Virtual Machine ای که توسط Nova کنترل می شود اصطلاحا یک Instance گفته می شود. زمانی که Hypervisor ها تحت عنوان Compute Node در اختیار مجموعه سرویس Nova قرار گرفته باشند، این Nova است که تصمیم می گیرد که هر کدام از Instance ها بر روی کدام host قرار بگیرند. به عبارت دیگر این Nova است که ارتباطات بین Hypervisor و Virtual Machine را مدیریت می کند تا (در یک مقیاس انبوه) با دنبال نمودن میزان مصرف منابع بر روی هر Host ، درخواست هایی نظیر ساخت، تغییر سایز و یا حذف یکInstance صورت پذیرد.در مقالات بعدی به ترتیب به بررسی هر کدام از قابلیت ها Nova و نقش آن ها در OpenStack خواهیم پرداخت.معرفی سرویس Nova در OpenStack قسمت 2 ابزار Flavorدر این مقاله به بررسی روش اصلی مورد استفاده در Openstack Nova Compute برای تعیین میزان حافظه، هسته ی پردازنده، اندازه دیسک و ... هر ماشین مجازی (که در اینجا با عنوان Instance شناخته می شود) خواهیم پرداخت، تا با نحوی مشخص کردن پارامترهای یک Instance بیشتر آشنا شویم.مفهوم Flavor در OpenStack Novaعبارت Flavor در لغت به معنای چاشنی و اما در اصطلاح Nova منظور فایل تنظیمات برای ساخت Instance می باشد. هنگام ساخت یک Instance باید تعیین شود که بر اساس کدام Flavor ساخته می شود. به عبارت دیگر برای لانچ یک Instance باید Flavor آن را تعیین نمود، چراکه Flavor اندازه آن Instance را تعیین می کند.درون یک Flavor می توان میزان منابع یک Instance و میزان بهره گیری از آنها را تعیین نمود، به عنوان مثال به کمک Flavor می توان تعیین نمود که هر Instance چه تعداد دیسک، و روی هر دیسک چه مقدار فضا داشته و همچنین هر Instance روی آن دیسک چقدر I/O بتواند استفاده کند. چنین مواردی برای تعیین سایر منابع یک Instance از قبیلRAM ، CPU ، Network و همچنین تعیین سایر شرایط یک Instance از قبیل میزانswap ، Bandwidth ، Secure Boot و ... نیز وجود دارد. علاوه بر این به وسیله Flavor می توان به ازای منابع هر Instance موارد Shares ، Limits و reservation را مطرح نمود.همچنین به کمک Flavor می توان تعیین نمود که کدام Instance بر روی کدام Compute Node قرار گیرد. در یک زیرساخت رایانش ابری با یک لیست ازFlavor ها سروکار خواهیم داشت که این Flavor ها می توانند در طبقه بندی های مختلف با Category های متفاوتی دسته بندی شده باشند. به عنوان مثال با Nova می توان یک Flavor فرضی با نام Fl101 با مشخصات ( 2CPU ، 6GB RAM ، 200GB SSD ، 1TB HDD و ... ) ایجاد نمود، تا زمان ساخت یک Instance تعیین شود که Instance مدنظر ما قرار است بر اساس Flavor ای با نام فرضیFl101 یا هر کدام ازFlavor های دیگر ساخته شود. همچنین درون مجموعه Nova به هرFlavor که ساخته می شود یک Flavor ID منحصربه فرد تعلق گرفته و با آن Flavor ID در سرتاسر مجموعهOpenStack شناسایی خواهد شد.شایان ذکر است که پارامترهای یکFlavor تنها محدود به کانفیگ سخت افزاری Instance ها می باشد، یعنیFlavor تعیین نمی کند که چه نوع سیستم عامل یا نرم افزاری درون Instance نصب شود. همچنین در نگارش این مقاله مفهوم Flavor Framework در Neutron لحاظ نشده است.هدف از وجود Flavor در زیرساخت ابری؛ پوشش طیف های گوناگون، وسیع و جورواجور از نیازهای کاربران می باشد تا بتوانند المان های سخت افزاری مناسب برای نرم افزارشان را داشته باشند.این زمانی معنا پیدا می کند که کاربر ترجیح داده به جای خرید فیزیکی سرور و راه اندازی آن، از IaaS استفاده نماید. بنابراین اگر OpenStack بدون استفاده از ابزار Flavor یک IaaS ارائه می داد، نمی توانست در یک مقیاس بزرگ درخواست های متنوع کاربران مختلف را (از حیث مشخصات سخت افزاری سرورمجازیشان) تامین نماید. به طور خلاصه؛ Flavor ها به ادمینIaaS یک راهکار آسان و راحت برای فیت کردن اندازه یک Instance با نیازهای سخت افزاری آن فراهم می کند، از سوی دیگر نیز کاربر تنها آنچه را که برای اهدافش نیاز دارد در اختیار خواهد گرفت.معرفی سرویس Nova در OpenStack قسمت 3 مفهوم rootwrapمفهوم rootwrap در OpenStack چیست؟ و rootwrap در زیرساخت ابری چه کاری انجام می دهد؟ در این مقاله کوتاه به بررسی Permission های سرویس هایOpenStack برای اجرا و همچنین مکانیسم های امنیتی لحاظ شده در آنها خواهیم پرداخت. برای درک منطق کاریrootwrap نیاز به آشنایی قبلی با محتوای فایل sudoers در سیستم عامل لینوکس هست، که تحت مالکیت کاربر root این فایل تعیین می کند چه کاربری، چه دستوری را ، با چه Privilege ای ، کجا و با چه نوع کنترلی می تواند اجرا کند. با این تفاوت کهOpenStack به جای استفاده از دستورات مکمل لینوکس و یا ویرایش خود فایل sudoers ، از فایل و مجموعه تنظیمات rootwrap (که باید تحت مالکیت کاربر root باشد) به صورت زنجیره ای در هنگام استارت کردن Compute Service ها استفاده می نماید.مفهوم Rootwrap در OpenStack Novaمجموعه سرویس Nova برای انجام برخی کارها نیاز به سطح دسترسی root سیستم عامل دارد، در حالی که همانند سایر سرویس ها به علت لحاظ برخی تمهیدات امنیتی مستقیما سطح کاربری root به آن داده نشده است. عبارت rootwrap به یک سازوکار امنیتی در OpenStack اطلاق می شود که باعث می گردد؛ دستور سرویسی ازOpenStack که با مشکل سطح دسترسی غیر از root مواجهه است، در مواقعی با سطح دسترسی کامل root اجرا شود.به عبارت دیگر rootwrap از یک مجموعه فایل و تنظیمات که به صورت زنجیره ای کار می کنند و تحت مالکیت کاربر root هستند استفاده می کند تا باعث شود که ؛ راهبرNova بتواند دستورات مشخصی از یک سرویس را (بدون مشکلpermission ای ) با privilege مربوط به کاربری root اجرا کند. در این حالت حتی Password مربوط به نام کاربری root هم پرسیده نمی شود. اما این مکانیسم تنها محدود بهcommand های خاصی است که پیش تر تعریف شده اند و پیش شرط آن هم این است که فایل rootwrap (و سایر فایل هایی که در آن ها filter definition انجام شده) تحت مالکیت کاربر root باشد.فواید روال کاری rootwrap و مکانیسم آن زمانی معنا پیدا می کند که به عنوان مثال یک هکر بخواهد از سطح دسترسی عملیاتی سرویسی که با کاربری root در حال اجرا می باشد برای حملات خود استفاده کند، وجود مکانیسم rootwrap دایره تحت نفوذ هکر را ایزوله کرده و میزان تخریب احتمالی را کاهش می دهد. چراکه rootwrap با هدف ارائه یک فیلترینگ با پارامترهای زیاد اجازه این محدودیت ها را برای تهدیدات احتمالی فراهم نموده است.شایان ذکر است که محل ذخیره فایل کانفیگ rootwrap در فایلsudoers و همچنین فایل اصلی تنظیمات Nova ، آدرس دهی شده است و از لحاظ دیدگاه سیستم عاملی اصطلاحا درون یک "trusted security path" جای داده شده است و تنها توسط کاربرroot قابل ویرایش است.معرفی سرویس Nova در OpenStack قسمت 4 سرویس novncproxyمنظور از novncproxy در OpenStack چیست؟ و novncproxy در زیرساخت ابری چه کاری انجام می دهد؟ در این مقاله کوتاه به بررسی تئوریک نحوه ی متصل شدن و دسترسی کاربر به Remote Console سرورهای مجازی بالا آمده در زیرساخت OpenStack خواهیم پرداخت. پیشنیاز این مقاله آشنایی با مفهومRemote Console و همچنینVNC هست که یک ارتباط گرافیکی را در بستر شبکه برای کنترل از راه دور ماشین ها فراهم می نماید.مفهوم novncproxy در OpenStack Novaیکی از متدهای Openstack برای ارتباط با سیستم عامل های مجازی، VNC می باشد. مجموعه سرویس Nova برای ارائه کنسول Instance ها از noVNC console استفاده می کند و novncproxy دسترسی به کنسول های روی Compute Node ها را فراهم می کند و باعث می شود که کاربر بتواند از طریق شبکه و با HTML5 کنسول Instance خود را باز کند. به عبارت دیگر novncproxy یک سرویس پراکسی است که مسئولیت برقراری ارتباطVNC به ماشین ها در بستر شبکه را فراهم کرده است و اجازه می دهد تا کاربر بتواند تحت وب به کنسول ماشین مجازی خود متصل شود. اهمیت novncproxy بدلیل سازگاری آن باNova و مدل زیرساخت Cloud Computing در OpenStack با قابلیت Encryption می باشد.در واقع پس از انجام احراز هویت های مورد نیاز OpenStack سرویس nova-novncproxy یک session رمزنگاری شده را روی مرورگر برقرار نگه می دارد و باعث می شود تا مشتریان زیرساخت IaaS بتوانند؛ ( حتی زمانی کهConnectivity هایی از قبیلSSH و ... به هر دلیلی میسر نبود اقدام به اتصال به سرور مجازی خود کنند. حتی در مواقعی که نیاز به ریست کردن پسورد باشد یا هنگامی که کاربری ناخواسته و به اشتباه دسترسی خودش را محدود کرده است، کاربر می تواند کنسول اولیه ماشین خود را با novncproxy ببیند. چراکه این اتصال همانند اتصال کیبورد و مانیتور به یک کامپیوتر می باشد که بدینوسیله محقق شده است. همچنین برای اتصالvnc console به درونInstance ها از Libvirt استفاده می شود که از آن به عنوان یک ابزار برای مدیریت ایمن Instance ها (ماشین های مجازی) بر روی Compute Node ها (هاست ها) در زیرساخت ابری Openstack یاد می شود.