سیستم فایل HDFS- قسمت سوم

Facebooktwittergoogle_pluspinterestlinkedinmail
Print Friendly, PDF & Email

پروتکل های ارتباطی

تمامی پروتکل های ارتباطی HDFS روی پروتکل TCP/IP قرار دارند. مشتری یک اتصال بر روی پورت TCP روی ماشین NameNode ایجاد می کند. کاربران با این پروتکل صحبت می کنند و DataNode هم با پروتکل خودش با NameNode ارتباط برقرار می کند. رویه ایجاد ارتباط از طریق Remote Procedure Call یا RPC می باشد که NameNode فقط به RPCهای آمده از کاربر یا DataNode پاسخ می دهد.

قدرت مندی

هدف اصلی HDFS ذخیره سازی مطمئن داده ها حتی در شرایط خرابی می باشد. 3 نوع رایج خرابی شامل خرابی DataNode، خرابی NameNode و پارتیشن های شبکه می باشد.

خطای دیسک داده: Re-Replication و Heartbeat

هرDataNode  بطور متناسب برای NameNode خود گزارش Heartbeat میفرستد. خطای شبکه ممکن از دست رفتن ارتباط DataNode با NameNodeشود.وقتیکه NameNode پیام های Heartbeat یک DataNode را دریافت نکند متوجه وجود مشکل می شود. سپس این DataNode را بعنوان یک گره مرده(Dead node) علامت گذاری می کند تا دیگر عمل I/O روی آن انجام ندهد. مرگ یک DataNode ممکن است باعث بهم خوردن نظم در فاکتور کپی سازی بلاک ها شود. به همین دلیل است که NameNodeبطور مداوم پیگیر این فاکتور از طریق گزارش های BlockReport می باشد تا در مواقع نیاز دستور کپی مجدد از بلاک ها را صادر کند.

بالانس دوباره کلاستر

معماری HDFS متناسب با اسکیماهای بالانس دوباره است. در یک اسکیما ممکن است تعدادی فایل بین DataNodeها جابجا شود چون مثلا فضای خالی DataNode از حد آستانه کمتر شده است. در مواقع خیلی ضروری و حیاتی نیاز زیاد به یک فایل، اسکیما ممکن است کپی های اضافی از فایل ایجاد کند و داده های درون کلاستر را دوباره بالانس کند.

یکپارچگی داده ها

امکان اینکه بلاک داده ای fetch شده از یک DataNode بصورت خراب به دست ما برسد وجود دارد. این خرابی ممکن است بعلت خطاها و خرابی های اتفاق افتاده در دستگاه ها یا مشکلات نرم افزاری رخ دهد. نرم افزار مشتری HDFS برای بررسی فایل های HDFS از یک checksum استفاده می کند. هنگامیکه کاربر یک فایل ایجاد می کند این چک سام برای بلاک های داده ای مختلف محاسبه می گردد و در یک فایل مخفی جداگانه در همان فضای نامی ذخیره می شود. وقتی که کاربر یک بلاک داده ای را دریافت می کند، این checksum را با checksum فایل دریافتی مطابقت می دهد.

خطای متاداده دیسک

ساختمان داده های مرکزی HDFS را Editlog و FsImage تشکیل می دهند. خرابی در این فایل ها موجب غیر کاربردی شدن آن نمونه HDFS می شود. این امکان در NameNode وجود دارد که چندین کپی از Editlog و FsImage نگهداری کند. هرگونه بروزرسانی در این فایل ها باعث بروزرسانی همزمان این کپی ها می شود. این بروزرسانی که دارای حجم بالایی است ممکن است عاملی تاثیرگذار در انجام دیگر تراکنش ها باشد. اما این کاهش سرعت را باید پذیرفت چراکه بروز نگه داشتن این فایل ها امری حیاتی می باشد. وقتی که NameNode دوباره شروع بکار کند به سراغ آخرین نسخه از این فایل ها می رود.

اگر یک NameNode دچار مشکل شود مداخله دستی مورد نیاز است و باید وارد عمل شد. تغییر خودکار نیز یکی از ویژگی هایی است که در نسخه های جدید تر HDFS در نظر گرفته  شده است.

Snapshots

Snapshotها یک نمونه کپی از فایل ها در زمان گذشته را نگهداری می کنند. ویژگی این ابزارها برگرداندن فایل ها به نسخه های سالم در زمان قبل تر از هنگامیکه به خرابی می خوریم می باشد.

بلاک های داده ای

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

Staging

درخواست کاربر برای ساخت فایل بطور مستقیم به NameNode فرستاده نمی شود. درواقع ابتدا در HDFS مشتری داده های فایل را در یک فایل محلی موقت کش می کند. دستورات نوشتن نرم افزارها بر روی این فایل ها اعمال می شوند. هنگامیکه داده های این فایل ها به اندازه یک بلاک داده ای HDFS رسید، مشتری با NameNode ارتباط برقرار می کند. سپس NameNode یک نام برای آن در سیستم خود ثبت می کند و فضایی را به آن اختصاص می دهد. پاسخی که از NameNode به مشتری می رسد حاوی شناسه DataNode و آدرس بلاک مورد نظر می باشد. سپس مشتری فایل موقت محلی خود را به آن آدرس ارسال می کند. پس از اینکه فایل بسته شد بقیه داده های موجود به DataNode فرستاده می شود. سپس مشتری بسته شدن فایل را به NameNode اطلاع می دهد. در این مرحله عملیات های لازم توسط NameNode بر روی فایل صورت می پذیرد. درصورتیکه قبل از بسته شدن فایل NameNode از کار بیفتد فایل از دست می رود.

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

Replicating Pipelining

همانطور که گفته شد وقتی مشتری در حال نوشتن در یک فایل HDFS است، داده های آن ابتدا در یک فایل محلی نوشته می شوند. فرض کنید یک فایل HDFS دارای فاکتور کپی سازی 3 می باشد. وقتیکه فایل محلی حجمی برابر یک بلاک داده ای در HDFS می گیرد، سیستم مشتری لیستی از DataNodeها را از NameNode می گیرد. این لیست حاوی DataNode هایی است که میزبانی کپی های بلاک را برعهده دارند. سپس مشتری داده ها را به اولین گره ارسال می کند. اولین گره شروع به دریافت داده در اندازه های کوچک(4 کیلوبایتی) می کند و پس از نوشتن آن در خود، آن حجم داده را به گره بعدی ارسال می کند. همین اتفاق و عملکرد برای 2 گره بعدی نیز انجام می شود. بنابراین یک DataNode می تواند همزمان هم داده از گره قبلی خود بگیرد و هم به گره بعدی ارسال کند بنابراین سیستم مدیریت ما بصورتPipeline با داده های خود برخورد می کند.

در دسترس بودن

HDFS را می توان با استفاده از روش های مختلف از درون نرم افزارها در دسترس داشت. بطور رسمی HDFS یک API جاوا ارائه کرده است. همچنین API به زبان C نیز موجود می باشد. یک ویژگی دیگر HDFS هم اینکه امکان دسترسی به نمونه های HDFS با استفاده از مرورگر و از طریق HTTP نیز فراهم شده است.

با ادامه این مطلب نیز با ما باشید.

مطالعه قسمت اول مطلب سیستم فایل HDFS

مطالعه قسمت دوم مطلب سیستم فایل HDFS

مطالعه قسمت سوم مطلب سیستم فایل HDFS

مطالعه قسمت آخر مطلب سیستم فایل HDFS

شما احتمالا این مطالب را نیز دوست دارید...

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *