مطلب ۱۲ : فایل سیستم توزیع شده هدوپ، نود

یک کلاستر HDFS دارای دو نوع نود می باشد که بر اساس یک الگوی master-worker طراحی شده اند: یک namenode  به عنوان master  و تعدادی datanode  به عنوان namenode .worker وظیفه مدیریت فضای عملیاتی فایل سیستم را برعهده دارد. این موجود از درخت فایل سیستم و فراداده (Metadata) تمامی فایل ها و پوشه های موجود روی درخت را نگهداری می نماید. اطلاعات همواره در قالب دو فایل روی دیسک محلی نگهداری می شود: namespace image و edit log. همچنین namenode تمامی datanode هایی که بلاک های مربوط به یک فایل روی آنها قرار گرفته را می شناسد، بنابراین نیازی به نگهداری موقعیت بلاک ها ندارد زیرا هنگام بارگذاری سیستم اطلاعات مورد نیاز در مورد آنها را از طریق datanode های مربوطه استخراج می نماید.

یک client به نیابت از یک کاربر می تواند از طریق ارتباط با namenode و datanode ها با فایل سیستم هدوپ ارتباط برقرار کند. از آنجایی که client به عنوان یک interface بین فایل سیستم و کاربر وجود دارد، از این رو کد نوشته شده توسط کاربر نیاز به شناخت چگونگی عملکرد namenode و datanode نخواهد داشت.

datanode ها خدمه فایل سیستم اند که براساس درخواست های ارسال شده (توسط client ها و یا namenode) بلاک ها را ذخیره و بازیابی می نمایند. آنها همچنین موظف اند بصورت دوره ای گزارشی در مورد بلاک های خود به namenode ارائه دهند.

بدون وجود namenode، فایل سیستم هدوپ غیر قابل استفاده می باشد. در واقع، اگر ماشینی که namenode روی آن در حال اجرا است بکلی از بین برود، دسترسی به بلاک های موجود روی datanode ها به منظور بازسازی فایل های ذخیره شده روی فایل سیستم امکان پذیر نخواهد بود. به همین خاطر، حفظ namenode هنگام وقوع رخدادهای غیر منتظره بسیار مهم می باشد، و البته هدوپ برای این موضوع دو مکانیزم پیشنهاد داده است.

اولین راه، گرفتن backup از فایل هایی که حاوی اطلاعات فراداده (Metadata)  فایل سیستم می باشند. این امکان در هدوپ وجود دارد که بتوان تنظیم نمود تا namenode بصورت کاملا یکپارچه و مطمئن روی چندین فایل سیستم اطلاعات خود را ثبت نماید. برای انجام این کار معمولا از دیسک محلی به علاوه یک دیسک remote استفاده می شود.

همچنین این امکان فراهم است تا یک secondary namenode در حال اجرا وجود داشته باشد، که برخلاف نام آن به عنوان یک namenode عمل نمی کند. مهمترین وظیفه آن انجام عملیات ادغام namespace image با edit log به منظور جلوگیری از حجیم شدن بیش از اندازه edit log در بازه های زمانی مشخص می باشد. از آنجایی که عملیات ادغام نیاز به استفاده از پردازشگر و همچنین میزان حافظه ای به اندازه حافظه namenode دارد، لذا secondary namenode بصورت کاملا مستقل روی یک ماشین جداگانه قرار می گیرد. این نود حاوی یک کپی از namespace image ادغام شده در خود می باشد، و در شرایط بحرانی هنگامیکه namenode به هر دلیلی از مدار خارج شود می تواند مورد استفاده قرار گیرد. با این حال، از آنجایی که secondary namenode با کمی فاصله عقب تر از namenode قرار دارد، از دست دادن مقداری داده محتمل می باشد. در این شرایط در صورتیکه راه اول در نظر گرفته شده باشد، این امکان وجود دارد تا اطلاعات فراداده (Metadata) مربوط به namenode را از دیسک remote روی secondary namenode کپی کرده تا بتوان آن را به عنوان namenode اصلی وارد مدار نمود.

Hadoop: The Definitive Guide by Tom White

استفاده از این مطلب با ذکر منبع بلامانع می باشد.