https://virgool.io/feed/@mobinranjbar مهندس کلان داده | عضو هیئت مدیره شرکت داده پایای سپهر | عضو هیئت مدیره شرکت مدیریت دارایی راسا fa 2026-06-16 16:47:52 https://files.virgool.io/upload/users/5593/avatar/5B96Me.jpg?height=120&width=120 https://virgool.io/@mobinranjbar https://virgool.io/bigdataengineer/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%B9%D9%85%D9%84%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D9%87%D8%A7%DB%8C-%DA%A9%D9%84%D8%A7%D9%86-%D8%AF%D8%A7%D8%AF%D9%87-%D8%A8%D8%AE%D8%B4-%D9%BE%D9%86%D8%AC%D9%85-l4rmphcj4uab در بخش قبل به نصب و پیکربندی ابزار Apache Ranger و پیکربندی هدوپ در آن پرداخته شد. در این بخش به ادامه مباحث مربوطه خواهیم پرداخت.توجه: اگر بخش قبل را مطالعه نکردید، به این لینک مراجعه کنید.اتصال سرویس های هدوپ به Ranger Adminپس از نصب افزونه سرویس های هدوپ می بایست آنها را در بخش Service Manager اضافه کنید. برای اینکار از منوی سرویس HDFS، گزینه + را انتخاب کنید تا صفحه اضافه کردن سرویس جدید باز شود. در صفحه باز شده فیلدهای خواسته شده را به صورت زیر تکمیل نمایید:فیلد Service Name نام سرویس هست که به دلخواه می توانید انتخاب کنید. دقت کنید که این نام می بایست با نامی که در هنگام نصب افزونه در مقدار REPOSITORY_NAME وارد کردید یکسان باشد.فیلدهای Username و Password را برابر با نام کاربری و کلمه عبور کاربر سرویسی که برروی سیستم عامل ساخته اید قرار دهید.فیلد Namenode URL را برابر با آدرس NameNode کلاستر قرار دهید(به طور مثال hdfs://masternode:9000).فیلد Authorization Enabled را برروی Yes تنظیم کنید.فیلد Authentication Type را برروی Kerberos تنظیم کنید.فیلد dfs.datanode.kerberos.principal را برابر با Principal مربوط به کاربر سرویس hdfs قرار دهید(به طور مثال hdfs/masternode@TEST.COM).فیلد dfs.namenode.kerberos.principal را برابر با Principal مربوط به کاربر سرویس hdfs قرار دهید(به طور مثال hdfs/masternode@TEST.COM).فیلد dfs.secondary.namenode.kerberos.principal را برابر با Principal مربوط به کاربر سرویس hdfs قرار دهید(به طور مثال hdfs/masternode@TEST.COM).فیلد RPC Protection Type را برروی Authentication تنظیم کنید.در بخش Add New Configuration سه مقدار زیر را به صورت مشخص شده تنظیم نمایید:مقدار policy.download.auth.users را برابر با نام کاربر سرویس(در اینجا hdfs) قرار دهید.مقدار tag.download.auth.users را برابر با نام کاربر سرویس(در اینجا hdfs) قرار دهید.مقدار policy.grantrevoke.auth.users را برابر با نام کاربر سرویس(در اینجا hdfs) قرار دهید.سه مقدار وارد شده در تنظیمات شماره 10، استانداردی است که می بایست برای تقریبا تمامی افزونه ها هنگام تعریف اضافه شوند. این مقادیر نام کاربر سرویس جهت دانلود آخرین سیاست ها توسط افزونه را مشخص می می کنند.در انتها با کلیک برروی گزینه Test Connection صحت اطلاعات وارد شده را بررسی و سپس برروی گزینه Save کلیک کنید. اگر اطلاعات وارد شده درست باشند و با موفقیت اتصال برقرار گردد، پیغام Connected Successfully به نمایش در خواهد آمد. در غیر اینصورت می بایست مشکل را برطرف نمایید.پس از تعریف سرویس HDFS به بخش Audit رفته و در سربرگ های Plugins و Plugin Status ارتباط موفقیت آمیز و وضعیت افزونه را مشاهده نمایید. اگر افزونه به درستی در حال کار با Ranger باشد، در سربرگ Plugins لیست ارتباط های موفقیت آمیز افزونه به Ranger را نشان می دهد و ستون Http Response Code برابر با 200 خواهد بود. همچنین در سربرگ Plugin Status هم در لیست، می توانید نام سرویس ساخته شده و آخرین وضعیت به روزرسانی سیاست ها را مشاهده نمایید. در شکل 10 و 11 وضعیت دو سربرگ Plugins و Plugin Status را مشاهده خواهید کرد.شکل 10 - وضعیت سربرگ Plugins پس از نصب افزونه و تعریف سرویسشکل 11 - وضعیت سربرگ Plugin Status پس از نصب افزونه و تعریف سرویستعریف سیاست های دسترسی در Ranger Adminبه منظور تعریف سیاست های دسترسی، پس از انتخاب سرویس و کلیک برروی آن به صفحه تعریف سیاست ها خواهیم رفت. در هنگام نصب افزونه، سیاست های پیش فرضی تعریف می شود که در برگیرنده کاربر سرویس و کاربر rangerlookup می باشند. به طور مثال در سرویس HDFS دو سیاست به نام all - path و kms-audit-path ساخته می شود که نشان دهنده وجود دسترسی کاربر hdfs به کل مسیرهای HDFS می باشد. کاربر rangerlookup وظیفه شناسایی و خزیدن در مسیرها را بر عهده دارد. به این معنی که این کاربر در هنگام تعریف سیاست جدید، مسیرهای موجود برروی HDFS را شناسایی کرده و برای سهولت در تعریف سیاست مبتنی بر منبع آنها را در بخش موردنظر لیست می کند.برای تعریف سیاست جدید برای کاربر خاص غیر سیستمی، می بایست آن کاربر در Ranger Admin تعریف شود. اینکار توسط ابزار Ranger UserSync به صورت خودکار انجام می گیرد. اما در صورت بروز مشکل در این ابزار و یا عدم استفاده از آن می بایست کاربر موردنظر در بخش Settings تعریف شود. کاربر موردنظر اگر به صورت خودکار ساخته شود، در ستون User Source مقدار External قرار می گیرد و اگر به صورت دستی ساخته شود مقدار Internal تنظیم می شود. لازم به ذکر است، پیش از ساخت کاربر می بایست گروه کاربری آن ساخته شود. سپس می توان با مراجعه به صفحه سیاست های سرویس موردنظر، برروی Add New Policy کلیک کرده و مقادیر زیر را به شکل مشخص شده تنظیم کنید:در بخش Policy Details مقدار Policy Name را برابر با نامی دلخواه برای سیاست جدید قرار دهید.در بخش Policy Details مقدار Resource Path را برابر با آدرس مسیری که قصد دارید برای آن سیاست گزاری کنید قرار دهید.در بخش Allow Conditions نام کاربر، نام گروه کاربری و یا نام نقش کاربر را وارد کرده و در بخش Permissions نوع دسترسی را انتخاب نمایید.در انتها برروی گزینه Add جهت ذخیره کلیک نمایید. پس از انجام اینکار در لیست سیاست ها، سیاست ساخته شده را می توانید مشاهده نمایید. اگر به بخش Audit و سربرگ Plugin Status مراجعه نمایید، در ستون Last Update مربوط به سطر افزونه سرویس HDFS مشاده خواهید کرد که در چند لحظه پیش سیاست های سرویس HDFS به روزرسانی شده است.در لیست سیاست های موردنظر امکاناتی از قبیل جستجوی سیاست، نمایش اطلاعات، ویرایش و حذف سیاست موردنظر وجود دارد که می توانید از آنها استفاده کنید.فرآیند تعریف سیاست جدید برای انواع دیگر سرویس ها هم مشابه سرویس HDFS می باشد و تفاوت در نوع دسترسی ها می باشد. دسترسی های مربوط به سرویس Hive و YARN را می توانید بررسی نمایید.نصب و راه اندازی افزونه Spark SQLنکته: لینک های موردنیاز در این بخش به دلیل محدودیت های ویرگول، در مخزن گیت هاب با نام links قرار گرفته است.در Ranger هیچ افزونه رسمی برای Spark ارائه نشده است و می بایست به صورت دستی، با استفاده از افزونه spark-ranger اتصال بین Spark و Ranger برقرار شود. لازم به ذکر است اتصال Spark به معنی اتصال سیاست گزاری های مربوط به جداول و پایگاه داده های موجود برروی Spark SQL می باشد که از طریق کتابخانه Hive صورت می پذیرد.پیش از شروع فرآیند نصب، فرض می شود که اسپارک در زیرساخت نصب شده و راه اندازی شده و همچنین لایه امنیتی Kerberos برروی آن فعال شده باشد.در ابتدا نیاز است که سورس کد افزونه spark-ranger را از لینک شماره 1 موجود در فایل links مخزن دانلود و سپس با استفاده از دستور زیر توسط Maven آنرا build کنید:mvn clean package -Pspark-2.4 -Pranger-2.0 -DskipTestsپس از build افزومه موردنظر، در پوشه target فایل spark-ranger-1.0-SNAPSHOT.jar ساخته می شود که نیاز است آنرا به پوشه $SPARK_HOME/jars منتقل کنید. پس از انجام اینکار فایل تنظیمات spark-defaults.conf را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و مقادیر زیر را در آن وارد کنید:spark.sql.extensions org.apache.ranger.authorization.spark.authorizer.RangerSparkSQLExtensionspark.driver.extraClassPath /usr/share/spark/jars/spark-ranger-1.0-SNAPSHOT./usr/share/spark/jars/gethostname4j-0.0.3./usr/share/spark/jars/jna-5.5.0.jarدر خط شماره 1 کلاس مربوط به افزونه را به اسپارک معرفی و در خط شماره 2 کتابخانه های موردنیاز آن کلاس را مقداردهی می کنیم. لازم به ذکر است افزونه spark-ranger نیاز به دو وابستگی gethostname4j و jna دارد که می توانید از لینک شماره 2 و شماره 3 موجود در فایل links مخزن دانلود نمایید. این دو فایل وابستگی نیز می بایست در مسیر $SPARK_HOME/jars قرار گیرد.پس از انجام عملیات بالا، در مسیر $SPARK_HOME/conf فایلی به نام ranger-spark-security.xml بسازید و آنرا با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.در خط شماره 3 آدرس کامل مربوط به Ranger Admin را وارد می کنیم و در خط 7 نام سرویسی که برروی Ranger Admin خواهیم ساخت را مقداردهی می کنیم. همچنین در خط 11 مسیر ذخیره سازی موقت سیاست های درخواستی تکرارپذیر را تنظیم می کنیم. در خط 15 مدت زمان دریافت سیاست ها توسط افزونه را به میلی ثانیه وارد می کنیم و در خط شماره 19 نیز کلاس جاوایی درخواست REST جهت دریافت آخرین سیاست ها از طریق Ranger Admin را تعیین می کنیم.این فایل را ذخیره کنید. فایلی به نام ranger-spark-audit.xml برای پیکربندی قابلیت گزارشات بازرسی در همان مسیر می بایست بسازیم و آنرا تنظیم کنیم. اگر در گذشته سرویس Hive را برروی Ranger Admin فعال کرده اید، کافی است این فایل را به مسیر $SPARK_HOME/conf کپی نمایید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.در خط شماره 2 قابلیت ایجاد گزارش بازرسی را فعال می کنیم. در خط 6 به افزونه اسپارک می گوییم گزارشات را میخواهیم به Solr بفرستیم. در خط 10 مقدار حداکثر حجم صف ارسال داده به Solr را مقداردهی می کنیم و در خط شماره 14 دوره زمانی تازه گردانی داده های ارسالی به Solr را به میلی ثانیه تعیین می کنیم. همچنین در خط شماره 18 آدرس کامل Core مربوط به Ranger را وارد می کنیم. در خط شماره 30 و 34 هم به ترتیب نام کاربری و کلمه عبور کاربر سیستم مالک سرویس Solr را وارد می کنیم. در خط شماره 38 استفاده و یا عدم استفاده از SolrCloud را تعیین می کنیم که در اینجا برابر با NONE است و در خط شماره 42 هم مسیر قرارگیری موقت داده های ارسالی به Solr تعیین می گردد.اگر در گذشته افزونه Hive را نصب نکرده اید، فایل موردنظر را بسازید و مقادیر موردنیاز ذکر شده در بالا را در آن قرار دهید. پس از انجام اینکار اسپارک و سرویس Thrift Server را دوباره راه اندازی نمایید تا تنظیمات جدید اعمال شود.پیش از تعریف سرویس Spark SQL برروی Ranger Admin می بایست کتابخانه های Hive موجود برروی Ranger Admin به روزرسانی گردند. اگر این مرحله انجام نشود، امکان اتصال موفقیت آمیز از طریق Test Connection، امکان لیست کردن پایگاه داده ها، جداول و ستون های آنها به صورت خودکار وجود نخواهد داشت. فایل های لیست شده در زیر را از مسیرهای مشخص شده به مسیر $RANGER_HOME/ews/webapp/WEB-INF/lib منتقل نمایید:hive-exec-1.2.1.spark2.jar (به دلیل استفاده Ranger از کتابخانه هدوپ نسخه 3، این فایل در بسته اسپارک موجود نیست و می بایست از لینک شماره 4 موجود در فایل links مخزن دانلود کنید).hive-jdbc-1.2.1.spark2.jar (از مسیر $SPARK_HOME/jars کپی کنید).hive-metastore-1.2.1.spark2.jar (از مسیر $SPARK_HOME/jars کپی کنید).hive-service-1.2.1.jar (از لینک شماره 5 موجود در فایل links مخزن دانلود نمایید).پس از انجام اینکار، یکبار Ranger Admin را با دستور زیر دوباره راه اندازی کنید:ranger-admin restartدر انتها، یک سرویس از نوع Hive در Ranger Admin بسازید و مقادیر زیر را مقداردهی کنید(بخشی از مقادیر این بخش مشابه سرویس HDFS می باشند که می توانید مشابه آنها مقداردهی کنید):فیلد Service Name نام سرویس هست که به دلخواه می توانید انتخاب کنید. دقت کنید که این نام می بایست با نامی که در هنگام ساخت فایل ranger-spark-security.xml وارد کردید یکسان باشد.فیلدهای Username و Password را برابر با نام کاربری و کلمه عبور کاربر سرویسی که برروی سیستم عامل ساخته اید قرار دهید.فیلد jdbc.url را برابر با آدرس اتصال JDBC مربوط به Thrift Server قرار دهید(به طور مثال jdbc:hive2://masternode:10000/default;principal=hive/masternode@TEST.COM).در بخش Add New Configuration سه مقدار زیر را به صورت مشخص شده تنظیم نمایید:مقدار policy.download.auth.users را برابر با نام کاربر سرویس(در اینجا hive) قرار دهید.مقدار tag.download.auth.users را برابر با نام کاربر سرویس(در اینجا hive) قرار دهید.مقدار policy.grantrevoke.auth.users را برابر با نام کاربر سرویس(در اینجا hive) قرار دهید.در انتها با کلیک برروی گزینه Test Connection صحت اطلاعات وارد شده را بررسی و سپس برروی گزینه Save کلیک کنید. اگر اطلاعات وارد شده درست باشند و با موفقیت اتصال برقرار گردد، پیغام Connected Successfully به نمایش در خواهد آمد. در غیر اینصورت می بایست مشکل را برطرف نمایید.نصب و راه اندازی Livy و اجرای مثال مرتبطجهت آزمایش و انجام یک مثال برروی Spark SQL نیاز است تا ابزار Livy را جهت انجام درخواست راه دور برروی زیرساخت نصب و راه اندازی کنیم. آخرین نسخه Livy را از سایت رسمی دانلود نمایید و در مسیر دلخواه(به طور مثال /opt) استخراج و مالک پوشه و دسترسی آنرا به کاربر livy تغییر دهید.پیش از تنظیم پیکربندی Livy می بایست Principal مربوط به Livy برروی Kadmin تعریف و فایل کلید آن را در مسیر تنظیمات Livy قرار دهیم. همچنین به علت ارتباط و استفاده Livy از HTTP می بایست فایل کلید آن نیز در مسیر تنظیمات این ابزار موجود باشد. به دلیل انجام این فرآیند در گذشته از مرور مجدد آن خودداری و به پیکربندی Livy می پردازیم.فایل livy.conf در مسیر $LIVY_HOME/conf را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر زیر را تنظیم نمایید:مقدار livy.server.host را برابر با نام میزبان ابزار Livy قرار دهید(در اینجا masternode).مقدار livy.server.port را برابر با شماره پورت دلخواه خود قرار دهید(به صورت پیش فرض 8998 انتخاب می شود).مقدار livy.impersonation.enabled را برابر با true قرار دهید. تنظیم این مقدار باعث می شود تا Livy بتواند از امکان proxyUser استفاده کند.مقدار livy.repl.enable-hive-context را برابر با true قرار دهید تا Livy بتواند هنگام کار با Spark SQL از دستورات Hive به صورت کامل پشتیبانی کند.مقدار livy.server.auth.type را جهت فعال سازی مکانیزم برابر با مقدار Kerberos قرار دهید.مقدار livy.server.auth.kerberos.principal را برابر با Principal مربوط به HTTP قرار دهید(به طور مثال HTTP/masternode@TEST.COM).مقدار livy.server.auth.kerberos.keytab را برابر با مسیر فایل کلید Principal مربوط به HTTP قرار دهید.مقدار livy.server.launch.kerberos.principal را وارد و برابر با Principal مربوط به کاربر livy قرار دهید.مقدار livy.server.launch.kerberos.keytab را وارد و برابر با آدرس فایل کلید مربوط به کاربر livy قرار دهید.پس از انجام اینکار با مراجعه به مسیر bin دستور زیر را جهت راه اندازی Livy اجرا کنید:./livy-serverحال فرض کنید کاربری می خواهد از راه دور برروی زیرساخت، عملیات پردازشی و یا ذخیره سازی را انجام دهد. در ابتدا این کاربر موجود در شبکه می بایست در kadmin تعریف گردد و مجوز احراز هویت دریافت نماید. نام کاربر موردنظر را به طور مثال mobin فرض کنید. در ابتدا این کاربر را به صورت زیر در Kadmin تعریف می کنیم:addprinc mobin/masternodeپس از انجام اینکار رمز عبور دلخواه از شما درخواست می شود که این رمز را می بایست به کاربر mobin بدهید و یا فایل کلید را تولید و برای او ارسال کنید تا بتواند خود را احراز هویت کند.در مرحله بعد کاربر mobin را می بایست واجد شرایط استفاده از پایگاه داده ها و منابع موجود برروی سرویس های HDFS، Spark SQL و YARN کنید. با مراجعه به Ranger Admin و تعریف سیاست مربوط به این کاربر، به او اعطای مجوز سرویس کنید. به طور مثال این کاربر می تواند تنها به پایگاه داده dbtest و مسیر مربوط به خود برروی HDFS دسترسی داشته باشد. فرآیند انجام اینکار قبلا توضیح داده شده است. لازم به ذکر است جهت استفاده livy از امکان proxyUser می بایست تنظیمات زیر برروی فایل core-site.xml هدوپ موجود باشد:<property><name>hadoop.proxyuser.livy.hosts</name><value>*</value></property><property><name>hadoop.proxyuser.livy.groups</name><value>*</value></property>همچنین دقت کنید که اگر Spark برروی YARN تنظیم شده باشد، کاربری که میخواهد از امکان proxyUser استفاده کند می بایست در تمامی ماشین های کلاستر به صورت سیستمی تعریف شده باشد.کاربر موردنظر با استفاده از نام Principal و رمزعبور خود یک kinit به صورت زیر برروی سیستم خود انجام می دهد تا بلیط خود را در حافظه موقت ذخیره کند و از آن برای ارسال درخواست خود استفاده کند. به صورت زیر:kinit mobin/masternodeپس از انجام دستور بالا، کاربر mobin جهت استفاده از زیرساخت کلان داده احراز هویت شده است. درخواست خود را به Livy به صورت زیر ارسال می کند:curl -ivf -negotiate -u : “http://masternode:8998/sessions” -header “Content-Type: application/json” -request POST -data ‘{“kind”:”sql”,”proxyUser”:”mobin”}’با اجرای دستور بالا به Livy می گوید من کاربر احراز هویت شده mobin میخواهم برروی Spark SQL یک Session دریافت کنم و عملیات پردازشی را برروی آن انجام دهم. اتفاقاتی که ممکن است برای این درخواست صورت بگیرد به شرح زیر است:کاربر mobin یک کاربر احراز هویت شده می باشد و دستور بالا کد 200 را بر میگرداند و Session موردنظر برروی Spark ایجاد می شود.کاربر mobin احراز هویت نشده است و یا چنین کاربری وجود ندارد. در این زمان، خطایی در خروجی دستور بالا به صورت زیر رخ می دهد و اعلام می کند که هیچ هویتی پیدا نشده است و کد خطای 401 را بر میگرداند:Gss_init_sec_context() failed : No Kerberos credentials available (default cache : FILE:/tmp/krb5cc_1000)حال فرض کنید کاربر mobin احراز هویت شده است اما درخواست خود را به این صورت ارسال می کند و میخواهد از مجوز دیگران استفاده و جعل هویت کند:curl -ivf -negotiate -u : “http://masternode:8998/sessions” -header “Content-Type: application/json” -request POST -data ‘{“kind”:”sql”,”proxyUser”:”admin”}’اتفاقی که برای درخواست بالا می افتد این است که با خطای 403 روبرو می شود و نشان می دهد که هویتی که این درخواست را ارسال کرده است، خود واقعی کاربر admin نیست و جعل هویت صورت گرفته است.در مثال انجام شده تفاوت عملی بین احراز هویت و اعطای مجوز را نشان می دهد و نقش مهم وجود مکانیزم Kerberos در کنار Ranger اثبات می شود. اگر به تنهایی Ranger را نصب و راه اندازی کنیم، هر کاربری می تواند جعل هویت کند و خود را به جای دیگری معرفی کند. مکانیزم Kerberos به تنهایی هم توانایی تفکیک مجوز سطح سرویس را ندارد و زمانی که کاربر احراز هویت می شود در واقع مجوز انجام هرکاری را دارا می باشد.ادامه دارد ...با من در بخش های دیگر این مستند همراه باشید و در صورت وجود ابهام و سوال و ارتباط با من می توانید با ایمیل من mobinranjbar1 روی جیمیل و یا لینکدین من مکاتبه کنید. مبین رنجبر مبین رنجبر Wed, 03 Sep 2025 11:08:16 +0330 https://virgool.io/bigdataengineer/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%B9%D9%85%D9%84%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D9%87%D8%A7%DB%8C-%DA%A9%D9%84%D8%A7%D9%86-%D8%AF%D8%A7%D8%AF%D9%87-%D8%A8%D8%AE%D8%B4-%DA%86%D9%87%D8%A7%D8%B1%D9%85-x11kojlkpwtg به روزرسانی: بخش پنجم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.در بخش قبل به پیکربندی هدوپ با قابلیت دسترس‌پذیری یا High Availability و معرفی ابزار Apache Ranger پرداخته شد. در این بخش به ادامه مباحث مربوطه خواهیم پرداخت.توجه: اگر بخش قبل را مطالعه نکردید، به این لینک مراجعه کنید.نصب و پیکربندی Ranger Adminپورتال مدیریت Ranger یعنی Ranger Admin پیش نیاز هایی برای نصب و راه اندازی دارد. لیست کامل نرم افزارها و ابزارهای پیش نیاز ضروری به شرح زیر می باشند:بسته JDK جاوا (نسخه 1.7 به بالا) به منظور اجرای RangerAdmin.نرم افزار Maven به منظور build کردن Apache Ranger.پایتون (آخرین به روزرسانی نسخه 2، ترجیها 2.7.16) به منظور اجرای فرآیند نصب Ranger Admin.یکی از پایگاه داده رابطه ای MySQL/MariaDB (نسخه 5.7 به بالا به غیر از نسخه 8)، اوراکل (نسخه نهایی)، Postgres (نسخه نهایی)، SQL Server (نسخه نهایی) جهت ذخیره سازی سیاست ها، اطلاعات کاربری و گزارشات.کتابخانه Client پایگاه داده رابطه ای در جاوا به منظور وارد کردن داده های موردنیاز نصب در پایگاه داده (به طور مثال اگر از MySQL استفاده می کنید وجود MySQL Connector for Java نیاز است).نرم افزار Kerberos (نسخه 5) به منظور اطمینان از عملکرد صحیح فرآیند احراز هویت و عدم سوء استفاده کاربران و جعل هویت.پیش نیاز های غیرضروری نیز به شرح زیر می باشند:فریم ورک Hadoop (نسخه 2.10.0 به بالا) جهت ذخیره سازی گزارشات بازرسی.نرم افزار Solr (نسخه 5.2.1 به بالا) جهت ذخیره سازی گزارشات بازرسی و جستجوی آنها. نکته قابل توجه این است که جهت ذخیره سازی گزارشات بازرسی در نسخه های قدیمی می توانستیم از سه ابزار پایگاه داده، HDFS و Solr استفاده کنیم اما در نسخه نهایی Apache Ranger فقط امکان استفاده از Solr وجود دارد و استفاده از آن پیشنهاد شده است. فرآیند نصب Solr نیز در ادامه بررسی خواهیم کرد.در ابتدا بسته Apache Ranger را از سایت رسمی دانلود می کنیم. نسخه موردنظر ما در این سند 2.0.0 می باشد. دقت کنید که تنها سورس کد این ابزار برای دانلود موجود است و می بایست توسط ابزار Maven آنرا build کنید. حجم فایل های نهایی Apache Ranger پس از build در حدود 1.5 گیگابایت خواهد بود. نرم افزار Maven را از سایت رسمی دانلود و استخراج کنید. سپس مسیر قرارگیری Maven را در فایل .bashrc به صورت زیر وارد کنید:export MAVEN_HOME=/opt/mavenexport PATH=$MAVEN_HOME/bin:$PATHفایل را ذخیره و دستور زیر را جهت اعمال تنظیمات اجرا کنید:source ~/.bashrcحالا با اجرای دستور mvn -version می بایست خروجی زیر نمایش یابد:Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T20:11:47+03:30)Maven home: /opt/mavenJava version: 1.8.0_111, vendor: Oracle CorporationJava home: /usr/lib/jvm/jdk1.8.0_111/jreDefault locale: en_US, platform encoding: UTF-8OS name: "linux", version: "4.15.0-91-generic", arch: "amd64", family: "unix"به همین صورت می تواند بسته jdk جاوا را نیز نصب کنید. با این تفاوت که در فایل .bashrc مقدار متغیر را برابر با JAVA_HOME قرار دهید.پس از انجام اینکار برای build کردن Apache Ranger با مراجعه به پوشه استخراج شده، دستور زیر را اجرا کنید:mvn clean compile package assembly:assembly installپس از انجام موفقیت آمیز دستور بالا، در پوشه target در همان مسیر فایل های فشرده مربوط به ابزارهای Apache Ranger با پسوند tar.gz را که در زیر لیست شده اند مشاهده خواهید کرد.ranger-<version>-admin.tar.gzranger-<version>-atlas-plugin.tar.gzranger-<version>-hbase-plugin.tar.gzranger-<version>-hdfs-plugin.tar.gzranger-<version>-hive-plugin.tar.gzranger-<version>-kafka-plugin.tar.gzranger-<version>-kms.tar.gzranger-<version>-knox-plugin.tar.gzranger-<version>-migration-util.tar.gzranger-<version>-ranger-tools.tar.gzranger-<version>-solr-plugin.tar.gzranger-<version>-sqoop-plugin.tar.gzranger-<version>-src.tar.gzranger-<version>-storm-plugin.tar.gzranger-<version>-tagsync.tar.gzranger-<version>-usersync.tar.gzranger-<version>-yarn-plugin.tar.gzranger-<version>-kylin-plugin.tar.gzranger-<version>-elasticsearch-plugin.tar.gzاین فایل ها بسته نصب ابزارها و افزونه های Ranger می باشند. پیش از کپی کردن این فایل ها برای استفاده، نیاز است تا کاربر اصلی مربوط به Apache Ranger را بسازید.با اجرای دستور زیر کاربری به نام ranger می سازیم و رمز عبور دلخواه خود را برای آن تعریف می کنیم. این کاربر مالک و اجراکننده سرویس های اصلی متعلق به Apache Ranger می باشد:sudo useradd rangersudo passwd rangerبرای نصب Ranger Admin به بسته ranger-admin.tar.gz نیاز داریم. ما به دلخواه ابزارهای مرتبط با Ranger را در مسیر /opt ذخیره می کنیم. فایل مربوطه با دستور زیر در مسیر /opt کپی و استخراج کنید:sudo cp ranger-admin.tar.gz /opt cd /opt sudo tar xvf ranger-admin.tar.gz sudo mv ranger-admin-2.0.0 ranger sudo chown -R ranger:ranger /opt/rangerدر خط شماره 1 فایل بسته Ranger Admin را به مسیر /opt کپی کردیم. در خط شماره 2 به پوشه /opt وارد می شویم و در خط 3 بسته را استخراج می کنیم. سپس در خط شماره 4 نام پوشه را به ranger تغییر نام و در خط آخر مالک پوشه موردنظر را به کاربر ranger تغییر می دهیم.در این مرحله پوشه مربوط به Ranger Admin آماده نصب است اما قبل از شروع فرآیند تنظیم و نصب می بایست نرم افزار های موردنیاز را به صورت کامل نصب نماییم.برای ذخیره سازی تنظیمات مربوط به Ranger Admin می بایست یکی از پایگاه داده رابطه ای برروی یکی از سرورها موجود باشد. در این سند ما از پایگاه داده MariaDB استفاده می کنیم. برای نصب MariaDB از دستور زیر استفاده می کنیم:sudo yum install mariadb-server mariadb-libs mariadbپس از نصب موفقیت آمیز آن، سرویس MariaDB را راه اندازی می کنیم. به صورت زیر:sudo systemctl start mariadbسپس سرویس مربوط به MariaDB را جهت اجرای خودکار در هنگام راه اندازی سیستم عامل به صورت زیر تنظیم می کنیم:sudo systemctl enable mariadbپس از اینکار می بایست نصب MariaDB را تکمیل کنیم. در این مرحله رمزعبور دلخواه مربوط به کاربر root سوال می شود که از اهمیت بالایی برخوردار است. این رمزعبور را برای استفاده در مراحل بعدی به خاطر بسپارید. برای اینکار دستور زیر را اجرا و فرآیند تکمیل نصب را ادامه دهید:sudo mysql_secure_installationدر مرحله بعد می بایست از طریق دستور زیر به کنسول مربوط به پایگاه داده MariaDB وارد شوید:mysql -u root -pبا اجرای دستور بالا رمز عبوری که در هنگام نصب وارد کرده اید را وارد کنید. پس از اینکار صفحه کنسول مربوط به MariaDB به صورت زیر اجرا می شود:Welcome to the MariaDB monitor. Commands end with ; or \g.Your MariaDB connection id is 410Server version: 5.5.64-MariaDB MariaDB ServerCopyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.MariaDB [(none)]>Ranger Admin جهت تعامل با MariaDB میبایست از کاربری که از قبل تعریف شده است استفاده کند. با استفاده از دستورات زیر کاربری به نام rangerdba در MariaDB می سازیم و دسترسی های لازم را برای آن تنظیم می کنیم. به صورت زیر:CREATE USER 'rangerdba'@'localhost' IDENTIFIED BY 'rangerdba'; GRANT ALL PRIVILEGES ON . TO 'rangerdba'@'localhost'; CREATE USER 'rangerdba'@'%' IDENTIFIED BY 'rangerdba'; GRANT ALL PRIVILEGES ON . TO 'rangerdba'@'%'; GRANT ALL PRIVILEGES ON . TO 'rangerdba'@'localhost' WITH GRANT OPTION; GRANT ALL PRIVILEGES ON . TO 'rangerdba'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;در خط شماره 1 کاربری به نام rangerdba و رمزعبوری به همین نام برروی میزبان localhost می سازیم. در خط شماره 2 تمامی دسترسی های موردنیاز برروی پایگاه داده ها را به این کاربر می دهیم. همچنین در خط شماره 3 همان کاربر را برروی میزبان های دیگر نیز تعریف میکنیم. در خطوط شماره 4 تا 6 دسترسی های کامل را به کاربر موردنظر داده و در نهایت در خط شماره 7 دسترسی ها را تازه گردانی می کنیم.در مرحله بعد با دستور زیر، پایگاه داده مربوط به Ranger Admin که ranger نام دارد را ایجاد می کنیم:create database ranger;نصب و پیکربندی MariaDB به پایان می رسد. در مرحله بعد به سراغ نصب Solr جهت ذخیره سازی گزارشات دسترسی می رویم.در این سند، برای ذخیره سازی گزارشات بازرسی از Solr استفاده خواهیم کرد. Solr یک سکوی جستجوی توزیع شده قدرتمند است که با استفاده از ابزار Apache Lucene امکاناتی مثل جستجوی Full-text، اندیس گزاری توزیع شده و... را فراهم می کند. Solr را می توان به صورت Standalone و Cloud راه اندازی نمود. در این پیکربندی Solr را به صورت Standalone راه اندازی خواهیم کرد. اگرچه بخواهیم Solr را در محیط تولید یا Production استفاده کنیم پیشنهاد می شود آنرا در حالت Cloud راه اندازی کنیم. این ابزار نقطه حساس کارایی بخش بازرسی Ranger Admin می باشد. Solr در استفاده از CPU، رم و دیسک پر مصرف است و باید میزبان قابل توجهی از این منابع در اختیار او باشد. اگر نرخ دسترسی ها در محیط شما زیاد است، پیشنهاد شده است که حجم دیسکی برابر با 1 ترابایت را در اختیار Solr قرار دهید. همچنین هرچقدر رم بالاتری به این ابزار تخصیص دهید کارایی مناسب تری خواهد داشت. مقدار 32 گیگابایت رم پیشنهاد شده است.برای نصب این ابزار نیاز است که بسته اجرایی Solr را از سایت رسمی آن دانلود نمایید و پس از آن در مسیر /opt استخراج نمایید. اگرچه ابزاری در Ranger Admin وجود دارد که می تواند Solr را به صورت اتوماتیک دانلود و تنظیم نماید. پیشنهاد می شود از این روش استفاده نکنید و به صورت دستی این کار را انجام دهید. در این مرحله فرض می شود که بسته Solr در مسیر /opt/solr وجود دارد. اما آنرا راه اندازی و پیکربندی نمی کنیم. با دستور زیر کاربری به نام solr بسازید و مالک این پوشه را به این کاربر تغییر دهید.sudo useradd solr sudo passwd solr sudo chown -R solr:hadoop /opt/solr به دلیل آنکه در بسته Ranger Admin ابزاری وجود دارد که یک Core برروی Solr می سازد که Ranger Admin از آن برای ذخیره سازی گزارشات بازرسی و جستجوی آنها استفاده می کند نیازی به پیکربندی و نصب آن نیست. Core در واقع یک Instance از اندیس Lucene است که برای انجام عملیات ذخیره سازی و اندیس گزاری از آن استفاده می شود.برای نصب این Core به مسیر /opt/ranger/ contrib/solr_for_audit_setup بروید و کاربر جاری را با دستور زیر به ranger تغییر دهید. زیرا که مالک این بسته کاربر ranger می باشد.su rangerسپس فایل install.properties را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و مقادیر زیر را در این فایل تغییر دهید:مقدار JAVA_HOME را برابر با مسیر نصب شده JDK قرار دهید.مقدار SOLR_USER و SOLR_GROUP را به ترتیب برابر با solr و solr قرار دهید.مقدار MAX_AUDIT_RETENTION_DAYS تعیین می کند که گزارشات بازرسی تا چند روز نگه داری شود. این مقدار به صورت پیش فرض برابر با 90 روز است که مناسب نیست. به دلخواه این مقدار را تغییر دهید.مقدار SOLR_INSTALL_FOLDER را برابر با مسیر نصب شده Solr یعنی /opt/solr قرار دهید.این تنظیمات دارای مقادیر دیگری نیز می باشد که در این قسمت به آنها نیاز نخواهیم داشت. پس از انجام مراحل بالا دستور زیر را جهت نصب Core اجرا کنید:sudo ./setup.shپس از اجرای موفقیت آمیز عملیات نصب، مسیر نصب شده Solr که می بایست اجرا شود /opt/solr/ranger_audit_server خواهد بود. با تغییر کاربر جاری به solr و مراجعه به پوشه scripts دستور زیر را جهت اجرای پردازه Solr مربوط به Core نصب شده اجرا نمایید:./start_solr.shبا اجرای موفقیت آمیز دستور بالا با مراجعه به آدرس http://masternode:6083 صفحه اصلی Core مربوط به Ranger را می توانید مشاهده کنید. این آدرس را در هنگام اعمال تنظیمات اصلی Ranger Admin به خاطر داشته باشید.قبل از پیکربندی تنظیمات اصلی Ranger Admin می بایست Principal های مورد استفاده Ranger Admin را در Kadmin بسازیم و فایل کلید آنها را در مسیر قابل دسترس برای کاربر ranger قرار دهیم. به ترتیب دستورات زیر را در Kadmin اجرا می کنیم:addprinc -randkey rangeradmin addprinc -randkey rangerlookup addprinc -randkey rangerusersync addprinc -randkey rangertagsync xst -kt /home/hdfs/rangeradmin.keytab rangeradmin/masternode xst -kt /home/hdfs/rangerlookup.keytab rangerlookup/masternode xst -kt /home/hdfs/rangerusersync.keytab rangerusersync/masternode xst -kt /home/hdfs/rangertagsync.keytab rangertagsync/masternode xst -kt /home/hdfs/spnego.service.keytab HTTP/masternode exitفایل کلیدهای ساخته شده در مسیر خصوصی کاربر hdfs ذخیره خواهند شد. علت اینکار این فایل کلید ها را می بایست در مسیر عمومی دلخواه منتقل و مالک آنرا به کاربر ranger تغییر و سطح دسترسی استاندارد را تنظیم نمایید. به صورت زیر:sudo mkdir -p /etc/security/keytabs sudo mv /home/hdfs/*.keytab /etc/security/keytabs sudo chown ranger:ranger /etc/security/keytabs/*.keytabهمچنین نیاز است که پایتون برروی ماشینی که قصد نصب Ranger Admin برروی آن را داریم موجود باشد. برای نصب پایتون نسخه 2.7.16 را از سایت رسمی آن دانلود نمایید و بسته موردنظر را استخراج نمایید. سپس دستورات زیر را در کنسول برای کامپایل وارد کنید(برای انجام عملیات موردنظر می بایست از نصب بسته gcc و make مطمئن شوید):cd Python-2.7.16 ./configure make sudo make installمورد دیگر از نیازمندی های ضروری، وجود کتابخانه Client جاوا است. به دلیل اینکه در این نصب از MySQL استفاده می کنیم کتابخانه mysql-connector-java را دانلود کرده و در مسیر /opt قرار میدهیم.در مرحله بعد به پیکربندی تنظیمات اصلی Ranger Admin می پردازیم. پیش از آن کاربر جاری را به ranger تغییر دهید.در مسیر /opt/ranger فایل install.properties را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و مقادیر زیر را تنظیم کنید:مقدار PYTHON_COMMAND_INVOKER به صورت پیش فرض python در نظر گرفته شده است. اگر در متغیر محیطی PATH مسیر کامل python موجود باشد نیازی به تغییر این مقدار نیست. اما اگر موجود نیست این مقدار را با مسیر کامل مربوط به پایتون تغییر دهید.مقدار DB_FLAVOR را برابر با نام پایگاه داده رابطه ای مدنظر خود قرار دهید. به صورت پیش فرض برروی MYSQL تنظیم شده است.مقدار SQL_CONNECTOR_JAR را برابر با مسیر قرارگیری کتابخانه Client جاوا مربوط به پایگاه داده موردنظر خود قرار دهید.مقادیر db_root_user، db_root_password و db_host را به ترتیب برابر با نام کاربر root، رمز عبور کاربر root و نام میزبانی که برروی آن MySQL نصب شده است قرار دهید.مقادیر db_name، db_user و db_password را به ترتیب برابر با نام پایگاه داده ساخته شده یعنی ranger، نام کاربر پایگاه داده یعنی rangerdba و رمزعبور آن قرار دهید.مقدار audit_store به صورت پیش فرض برروی solr تنظیم شده است و در نسخه نهایی تنها می توان از آن استفاده کرد. از این مقدار بدون تغییر عبور کنید.مقادیر audit_solr_urls، audit_solr_user و audit_solr_password را به ترتیب برابر با آدرس Core ساخته شده برروی Solr(در اینجا http://masternode:6083/solr/ranger_audits)، نام کاربر سرویس Solr و رمز عبور آن قرار دهید. در صورت استفاده از حالت Cloud می توانید مقدار audit_solr_zookeepers را تنظیم کنید.مقدار policymgr_external_url را برابر با نام میزبان و شماره پورت دلخواه خود(به صورت پیش فرض 6080) قرار دهید.مقادیر unix_user، unix_user_pwd و unix_group را به ترتیب برابر با کاربر مالک پوشه ranger، رمزعبور و گروه کاربری آن قرار دهید.مقدار spnego_principal را برابر با Principal کامل مربوط به HTTP قرار دهید(به طور مثال HTTP/masternode@TEST.COM.مقدار spnego_keytab را برابر با آدرس فایل کلید Principal بالا قرار دهید(آدرس کامل فایل کلید ساخته شده با نام spnego.service.keytab را در اینجا وارد نمایید).مقدار cookie_domain را برابر با نام میزبان Ranger Admin قرار دهید(در اینجا masternode).مقدار admin_principal را برابر با Principal مربوط به rangeradmin(به طور مثال rangeradmin/masternode@TEST.COM) قرار دهید.مقدار admin_keytab را برابر با آدرس فایل کلید Principal قبلی قرار دهید.مقدار lookup_principal را برابر با Principal مربوط به کاربر rangerlookup قرار دهید(به طور مثال rangerlookup/masternode@TEST.COM).مقدار lookup_keytab را برابر با آدرس فایل کلید Principal قبلی قرار دهید.مقدار hadoop_conf را برابر با آدرس قرارگیری تنظیمات مربوط به هدوپ قرار دهید(به طور مثال /usr/share/hadoop/etc/hadoop).پس از انجام پیکربندی بالا، دستور زیر را جهت شروع فرآیند نصب Ranger Admin اجرا کنید:sudo ./setup.shبا اجرای موفقیت آمیز دستور بالا، پیغام زیر در خروجی چاپ می شود:Installation of Ranger PolicyManager Web Application is completed.برای راه اندازی سرویس Ranger Admin دستور زیر را اجرا کنید:ranger-admin startبا مراجعه به آدرس http://masternode:6080 در مرورگر، صفحه ورود مربوط به Ranger Admin را می توانید مشاهده کنید. لازم به ذکر است کلمه عبور و رمز عبور پیش فرض برای ورود به این محیط admin و admin است که نیاز است در هنگام استفاده در محیط عملیاتی تغییر دهید.نصب و پیکربندی Ranger UserSyncبرای نصب و پیکربندی Ranger UserSync می بایست بسته فشرده مربوط به آن به نام ranger-usersync.tar.gz را در مسیر دلخواه(در اینجا /opt) کپی و استخراج نمایید. پیش از انجام پیکربندی موردنیاز این ابزار، نیاز است که در مسیر /etc/ranger/usersync/conf/cert/ کلید رمز مربوط به این سرویس توسط ابزار Keytool در جاوا تولید شود. این ابزار در LDAP مورد استفاده قرار می گرد اما برای نصب این ابزار ضروری است. برای اینکار، دستورات زیر را اجرا نمایید:sudo mkdir -p /etc/ranger/usersync/conf/cert/ sudo keytool -genkeypair -keyalg RSA -alias selfsigned -keystore /etc/ranger/usersync/conf/cert/unixauthservice.jks -keypass UnIx529p -storepass UnIx529p -validity 3600 -keysize 2048 -dname 'cn=unixauthservice,ou=authenticator,o=mycompany,c=US' sudo chown -R ranger:ranger /etc/ranger/usersync/conf/cert sudo chmod -R 400 /etc/ranger/usersync/conf/certدر خط شماره 1 پوشه استاندارد مربوط به فایل کلید رمز ساخته می شود. در خط شماره 2، با استفاده از ابزار keytool در جاوا فایل کلید را ایجاد می کنیم. در خطوط شماره 3 و 4 نیز مالک و دسترسی پوشه محتوی فایل کلید رمز را تغییر می دهیم.پس از انجام اینکار با مراجعه به پوشه آن، فایل پیکربندی install.properties را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و مقادیر زیر را مقداردهی کنید:مقدار POLICY_MGR_URL را برابر با آدرس URL مربوط به Ranger Admin قرار دهید(به طور مثال http://masternode:6080).مقدار SYNC_SOURCE را برابر با یکی از دو مقدار unix و ldap قرار دهید. این مقدار به منظور انتخاب منبع همسان سازی کاربری مورد استفاده قرار می گیرد. اگر برروی مقدار unix قرار گیرد، منبع همسان سازی کاربران سیستم عامل خواهد بود و اگر برروی ldap قرار گیرد منبع همسان سازی LDAP خواهد بود. تنها این دو مقدار در Ranger پشتیبانی می شوند.مقدار SYNC_INTERVAL برای تعیین دوره زمانی همسان سازی به دقیقه به کار می رود. این مقدار اگر مقداردهی نشود، به صورت پیش فرض در منبع unix 5 دقیقه در نظر گرفته می شود و در منبع LDAP 360 دقیقه تعیین می شود.مقادیر unix_user و unix_group را به ترتیب برابر با کاربر مالک سرویس یعنی ranger و گروه کاربری آن قرار دهید.مقدار usersync_principal را برابر با Principal مربوط به rangerusersync قرار دهید(به طور مثال usersync/masternode@TEST.COM).مقدار usersync_keytab را برابر با آدرس فایل کلید Principal قبلی قرار دهید.مقدار hadoop_conf را برابر با آدرس قرارگیری تنظیمات مربوط به هدوپ قرار دهید(به طور مثال /usr/share/hadoop/etc/hadoop).پس از انجام تنظیمات بالا، دستور زیر را جهت نصب Ranger UserSync اجرا کنید:sudo ./setup.shپس از نصب موفقیت آمیز، برای اجرای سرویس از دستور زیر استفاده کنید:./ranger-usersync-services.sh startنصب و راه اندازی افزونه هدوپ(سرویس HDFS و YARN) در Ranger Adminبرای نصب افزونه مربوط به سرویس های اصلی هدوپ می بایست بسته فشرده مربوط به آن افزونه را به مسیر مناسب منتقل و سپس استخراج کنید. برای سرویس HDFS به افزونه ranger-hdfs-plugin.tar.gz و برای سرویس YARN به افزونه ranger-yarn-plugin.tar.gz نیاز داریم. این فایل ها را از محل ذکر شده در هنگام نصب Ranger Admin به مسیر دلخواه(در اینجا /opt منتقل و سپس آنرا استخراج نمایید. لازم به ذکر است نیاز است که مالک پوشه استخراج شده را به ranger تغییر دهید. پس از انجام اینکار، فایل تنظیمات install.properties در پوشه افزونه را توسط یکی از ویرایشگرهای متنی برای ویرایش باز کنید و مقادیر زیر را مقداردهی کنید(مقادیر مربوط به تنظیمات پیش از نصب افزونه ها تقریبا مشابه یکدیگر هستند):مقدار POLICY_MGR_URL را برابر با آدرس URL مربوط به Ranger Admin قرار دهید(به طور مثال http://masternode:6080).مقدار REPOSITORY_NAME را برابر با نام دلخواه سرویس موردنظر که در Ranger Admin خواهید ساخت قرار دهید. دقت نمایید که پس از نصب افزونه نیاز است که سرویس موردنظر در بخش Access Manager اضافه گردد. این سرویس دارای نامی است که می بایست با نامی که در اینجا مقداردهی کرده اید برابر باشد).مقدار COMPONENT_INSTALL_DIR_NAME را برابر با مسیر اصلی هدوپ مقدار دهی کنید.مقدار XAAUDIT.SOLR.ENABLE را جهت فعال سازی امکان ذخیره سازی گزارشات بازرسی در Solr فعال و برابر با true قرار دهید.پس از فعال سازی مقدار قبلی، مقدار XAAUDIT.SOLR.URL را برابر با آدرس کامل Core مربوط به Ranger(به طور مثال http://masternode:6083/solr/ranger_audits قرار دهید).مقدار XAAUDIT.SOLR.USER و XAAUDIT.SOLR.PASSWORD را به ترتیب برابر با نام کاربر مالک Solr و رمزعبور آن قرار دهید.در صورت استفاده از حالت Cloud در Solr، مقدار XAAUDIT.SOLR.ZOOKEEPER را مقداردهی کنید.مقدار XAAUDIT.SOLR.IS_ENABLED را جهت فعال سازی Solr مجددا برابر با true قرار دهید.مقدار XAAUDIT.SOLR.SOLR_URL را برابر با آدرس کامل Core مربوط به Ranger(به طور مثال http://masternode:6083/solr/ranger_audits قرار دهید).مقادیر CUSTOM_USER و CUSTOM_GROUP را به ترتیب برابر با کاربر مالک سرویس و گروه کاربر آن قرار دهید.سپس برای نصب افزونه دستور زیر را وارد نمایید:sudo ./enable-hdfs-plugin.shپس از فعال سازی افزونه، می بایست سرویس دوباره راه اندازی شود. قبل از اینکار می بایست به مسیر تنظیمات هدوپ بروید و فایل ranger-hdfs-security.xml را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید. در انتهای این فایل مقدار زیر را برابر با false قرار دهید:<property><name>xasecure.add-hadoop-authorization</name><value>false</value></property>با تغییر مقدار بالا، در واقع به Ranger گفته اید که لایه امنیتی ACL هدوپ را به فریم ورک Ranger اضافه نکن. علت این است که Apache Ranger قابلیت مدیریت و کنترل مرکزی امنیت زیرساخت کلان داده را بر عهده دارد و تصمیمات دسترسی می بایست فقط از طریق Ranger انجام شود. اگر این گزینه فعال باشد، ایجاد و اعمال هرگونه سیاست در Ranger مبتنی بر دسترسی های ACL موجود برروی HDFS خواهد بود. به این معنی که لایه امنیتی ACL در اولویت بالاتری نسبت به Ranger قرار خواهد گرفت. فرض کنید در Ranger دسترسی کاربر ali را به پوشه x برروی HDFS محدود می کنید اما سطح دسترسی این پوشه به ali اجازه دسترسی را داده است. در این سناریو، اولویت با سطح دسترسی هدوپ است و اجازه دسترسی به ali داده می شود و Ranger نقشی در سیاست گزاری نخواهد داشت.فایل بالا را ذخیره کنید و برای اعمال فعال سازی افزونه برروی سرویس HDFS، یکبار هدوپ را مجددا راه اندازی نمایید. به صورت کلی در پس از نصب افزونه مربوط به هر سرویس، برای اعمال کارکرد می بایست یکبار سرویس دوباره راه اندازی شود.فرآیند نصب مربوط به YARN نیز مشابه افزونه HDFS می باشد.ادامه دارد ...به روزرسانی: بخش پنجم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.با من در بخش های دیگر این مستند همراه باشید و در صورت وجود ابهام و سوال و ارتباط با من می توانید با ایمیل من mobinranjbar1 روی جیمیل و یا لینکدین من مکاتبه کنید. مبین رنجبر مبین رنجبر Sun, 31 Aug 2025 12:41:17 +0330 https://virgool.io/bigdataengineer/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%B9%D9%85%D9%84%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D9%87%D8%A7%DB%8C-%DA%A9%D9%84%D8%A7%D9%86-%D8%AF%D8%A7%D8%AF%D9%87-%D8%A8%D8%AE%D8%B4-%D8%B3%D9%88%D9%85-wir1slmpqqfg به روزرسانی: بخش چهارم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.در بخش قبل به نصب و راه اندازی Kerberos و پیکربندی آن در هدوپ پرداخته شد. در این بخش به ادامه مباحث مربوطه خواهیم پرداخت.توجه: اگر بخش قبل را مطالعه نکردید، به این لینک مراجعه کنید.پیکربندی هدوپ با قابلیت دسترس‌پذیری یا High Availabilityبه منظور پیکربندی هدوپ با قابلیت دسترس‌پذیری، مراحل نصب هدوپ به صورت عادی می بایست انجام گیرد و تنها تفاوت این نوع نصب در این است که نیاز به اضافه کردن پیکربندی های بیشتری می باشد که در ادامه به آنها خواهیم پرداخت.قبل از پرداختن به پیکربندی و تنظیمات موردنظر، می بایست با معماری این قابلیت آشنا شویم. در شکل 3 نمای کلی از معماری دسترس‌پذیری هدوپ را می توانید مشاهده کنید.شکل 3به منظور فراهم آوری قابلیت دسترس‌پذیری در زیرساخت هدوپ، ماشین های متعدد NameNode را راه اندازی می کنیم تا در زمان اشکال در یکی از این ماشین ها، دیگری بتواند پاسخگوی درخواست ها باشد. این قابلیت از طریق ایجاد معماری Active/Passive صورت می گیرد. به این صورت که اگر 2 ماشین NameNode داشته باشیم، یکی از آنها در حالت Active می ماند و دیگری در حالت Standby. در مواقع خطا و اشکال اگر ماشین Active از دسترس خارج شود، ماشین Standby به Active تغییر وضعیت داده و درخواست ها را مدیریت می کند. تعداد ماشین های NameNode می تواند از 2 بیشتر باشد اما به دلیل جلوگیری از افت کارایی ارتباط پیشنهاد می شود که از 5 عدد بیشتر نباشد. نکته قابل توجه در اینجا این است که این قابلیت مختص سرویس HDFS نیست و سرویس YARN نیز با ایجاد معماری Active/Passive برروی Resource Manager این کار را انجام می دهد. برای پیاده سازی این روش، نیاز به راه اندازی سرویس ها و پیکربندی خاصی است که در ادامه شرح خواهیم داد.در این معماری موجودیت های زیر به ساختار اصلی هدوپ اضافه می شوند که در زیر آنها را معرفی خواهیم کرد:1. سرویس ZooKeeper : این سرویس به منظور ایجاد قابلیت Automatic Failover راه اندازی می شود. پس از اینکه ماشین NameNode Active با مشکل و خطا روبرو شد، هدوپ به صورت خودکار قادر نخواهد بود که ماشین Standby را به Active تغیر وضعیت دهد و به نوعی مانع از انتقال احساس مشکل به کاربر شود. این فرآیند که Manual Failover نامیده می شود از مدیرسیستم می خواهد که خودش به صورت دستی فرآیند حل مشکل را انجام و ماشین Standby را به Active تغییر وضعیت دهد. با استفاده از سرویس ZooKeeper این فرآیند به صورت خودکار انجام خواهد شد. این سرویس که به صورت کلاستر راه اندازی می شود می تواند در برگیرنده چند ماشین باشد.2. سرویس JournalNode : ماشین های NameNode حاوی ابرداده ها یا metadata می باشند که همزمانی آنها برروی این ماشین ها از اهمیت بالایی برخوردار است. وجود سرویس JournalNode باعث می شود که تغییرات رخ داده برروی داده ها برروی تمامی NameNode های دیگر هم اعمال شود و همواره به روز باشد. این سرویس نیز به صورت کلاستر راه اندازی می شود و می تواند از یک ماشین بیشتر باشد.نکته: به جای سرویس JournalNode می توان از قابلیت NFS یا Network File System به منظور ذخیره سازی یکپارچه ابرداده ها استفاده نمود. اما پیشنهاد می شود که از JournalNode استفاده شود. به این دلیل که مشکلات احتمالی در Mount کردن این فایل سیستم باعث از دسترس خارج شدن کل کلاستر و عدم دسترسی به داده ها خواهد شد.3. سرویس ZKFC : این سرویس که مخفف ZooKeeper Failover Controller می باشد وظیفه بررسی سلامت NameNode ها و برگزاری انتخابات بین آنها را بر عهده دارد. در واقع ماشین NameNode وضعیت خود را به ZooKeeper اعلام نمی کند، بلکه این سرویس در مدت زمان مشخص سلامت NameNode را بررسی نموده و وضعیت آنرا به سرویس ZooKeeper اعلام می کند. سرویس ZKFC از نگاهی دیگر یک سرویس گیرنده ZooKeeper است. این سرویس عموما برروی همه ماشین های NameNode راه اندازی می شود تا هرکدام از آنها وظایف خود را برروی ماشین میزبان انجام دهند.در ادامه به نصب و پیکربندی این قابلیت در هدوپ خواهیم پرداخت.در این مثال کلاستر هدوپ ما دارای 3 ماشین می باشد که طبق جدول شماره 3 نقش های آنها را مشخص خواهیم کرد.جدول 3برای نصب و راه اندازی این قابلیت می بایست تمامی مراحل نصب اصلی هدوپ که پیش از این به آن پرداختیم، انجام شده باشد.در ابتدا می بایست بسته باینری مربوط به نرم افزار ZooKeeper را از این لینک دانلود و در مسیر دلخواه(به طور مثال /usr/share) استخراج و مالک پوشه و دسترسی آنرا به کاربر zoo تغییر دهید(اگر این کاربر وجود ندارد آنرا ایجاد کنید). ما در این مثال، از نسخه 3.6.1 استفاده می کنیم. دقت نمایید که این عملیات را برروی تمامی ماشین هایی که نقش ZooKeeper را بازی می کنند، اجرا کنید.پس از اینکار با مراجعه به پوشه conf فایل zoo_sample.cfg را با استفاده از دستور زیر تغییر نام دهید و سپس با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید:su zoomv zoo_sample.cfg zoo.cfgمقدار موجود در این فایل را به صورت زیر تغییر دهید:dataDir=/usr/share/zookeeper/dataمقدار بالا مسیر دلخواه جهت ذخیره سازی فایل های داده ای ZooKeeper را مشخص می کند.سپس مقادیر زیر را در انتهای فایل موردنظر قرار دهید و فایل را ذخیره کنید:Server.1=masternode1:2888:3888Server.2=masternode2:2888:3888Server.3=slavenode1:2888:3888در خطوط 1 تا 3 نام میزبان سرورهایی که می خواهید برروی آنها سرویس ZooKeeper را فعال کنید قرار می گرد. در اینجا می توانید سرورهای بیشتری نیز انتخاب کنید. پس از نام میزبان دو شماره پورت قرار می گیرد که پورت اول برای ارتباط بین ماشین های ZooKeeper با همدیگر و پورت بعدی برای انتخابات بین ماشین ها انتخاب می شود.با مراجعه به پوشه bin در هر ماشین، دستور زیر را برای اجرای سرویس ZooKeeper اجرا کنید:./zkServer.sh startپس از اجرای موفقیت آمیز دستور بالا، با اجرای دستور jps می بایست سرویس QuorumPeerMain را در خروجی مشاهده کنید.در مرحله بعد فایل core-site.xml از پوشه etc/hadoop در هر ماشین را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.مقدار موجود در خط شماره 2 در واقع آدرس NameNode پیش فرض است که در حالت دسترس‌پذیری می بایست برای ماشین های NameNode یک فضای نام دلخواه انتخاب کنیم تا هرکدام از NameNode ها که در وضعیت Active بود پاسخگوی درخواست ها باشد. در اینجا این نام را به دلخواه hdfscluster انتخاب می کنیم.در مرحله بعد فایل hdfs-site.xml از پوشه etc/hadoop در هر ماشین را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.در خط شماره 2 نام دلخواه مربوط به فضای نام را که در اینجا hdfscluster انتخاب کردیم قرار می دهیم. در خط شماره 6 برای این فضای نام، شناسه های یکتای دلخواه مربوط به هر ماشین NameNode را قرار می دهیم. در خطوط شماره 10 تا 22 نیز به ترتیب آدرس های میزبان و شماره پورت های RPC و http مربوط به هر NameNode را مقداردهی می کنیم. در خط شماره 26 آدرس های ماشین های JournalNode را تعیین می کنیم. در خط شماره 30 تعیین می کنیم که نام کلاس استاندارد جاوایی است که هر سرویس گیرنده از آن برای اتصال به ماشین NameNode با وضعیت Active استفاده می کند. اگر این مقدار وجود نداشته باشد اجرای دستورات مربوط به کار با HDFS با خطای عدم دسترسی به NameNode مواجه می شود. به این دلیل که هدوپ به صورت پیش فرض فکر می کند که یک ماشین NameNode وجود دارد و به دنبال آدرس آن در پیکربندی می گردد. در خط شماره 34 قابلیت Automatic Failover را فعال می کنیم. بلافاصله در خط شماره 38 آدرس ماشین های میزبان و شماره پورت مربوط به ZooKeeper جهت فعال سازی Automatic Failover را تعیین می کنیم. در خط شماره 42 روش مربوط به عملکرد Fencing را مقداردهی می کنیم. عملکرد Fencing روشی برای جلوگیری از اجرا ماندن NameNode ای است که دچار خطا شده است اما هنوز در حالت Active قرار دارد و به درخواست ها پاسخ می دهد. به این معنی که در کلاستر دارای دو NameNode با وضعیت Active خواهیم بود. همواره هدوپ اجازه اجرای یک گره NameNode با وضعیت Active را می دهد تا داده ها دچار خرابی نشوند. در هنگام خطا اگر NameNode همچنان به فعالیت خود ادامه دهد، به دلیل استفاده از ابرداده های قدیمی و نامعتبر، پایداری داده ها را با مشکل مواجه خواهد کرد. روش موردنظر ما برای این عملکرد sshfence خواهد بود که در شرایط ذکر شده، پردازه مربوط به NameNode را Kill می کند. در خط شماره 46 نیز مسیر قرارگیری کلیدهای ssh برای ارتباط با ماشین NameNode را تعیین می کنیم. در خطوط شماره 50 تا 58 نیز Principal ها و مسیر قرارگیری فایل کلیدهای مربوط به ماشین های JournalNode که با NameNode یکسان می باشد را مشخص می کنیم. مقادیری که با رنگ قرمز و سبز مشخص شده اند مقدار دلخواهی می باشند که در پیکربندی تعیین می شوند.تا به حال پیکربندی مربوط به HDFS را بررسی و انجام داده ایم و حال می بایست پیکربندی مربوط به YARN را انجام دهیم.برای این کار فایل yarn-site.xml از پوشه etc/hadoop در هر ماشین را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.در خط شماره 2 قابلیت دسترس‌پذیری را برای ResourceManager سرویس YARN فعال می کنیم. در خط شماره 6 نیز مشابه سرویس HDFS یک فضای نام یا شناسه کلاستر دلخواه را تعیین و انتخاب می کنیم. در اینجا این شناسه را yarncluster قرار می دهیم. در خط شماره 10 شناسه های مربوط به ماشین هایی که می خواهیم سرویس ResourceManager را برروی آنها اجرا کنیم را وارد می کنیم. خطوط شماره 14 تا 26 نیز به ترتیب نام میزبان و شماره پورت های ماشین های ResourceManager را مقداردهی می کنیم. در خط شماره 30 هم نام میزبان و شماره پورت های مربوط به ماشین های سرویس دهنده ZooKeeper را تعیین می کنیم.در مرحله نهایی می بایست سرویس های ذکرشده در بالا را راه اندازی کنیم. تا به حال سرویس ZooKeeper را بر روی ماشین های موردنظر راه اندازی کردیم. در مرحله بعد با مراجعه به مسیر sbin از پوشه هدوپ، سرویس JournalNode را در هر ماشین با استفاده از دستور زیر راه اندازی می کنیم:./hadoop-daemon.sh start journalnodeبرروی ماشین NameNode اول، دستور زیر را در پوشه bin جهت format کردن فایل سیستم اجرا می کنیم:./hdfs namenode -formatسپس سرویس NameNode اول را با استفاده دستور زیر در پوشه sbin راه اندازی می کنیم:./hadoop-daemon.sh start namenodeبرروی ماشین های دیگر NameNode نیاز به format کردن نیست و کافی است دستور زیر را از پوشه bin جهت انتقال یک کپی از ابرداده ها برروی آن ماشین اجرا می کنیم:./hdfs namenode -bootstrapStandbyدر مرحله بعد سرویس NameNode برروی ماشین های Standby را با استفاده از دستور زیر راه اندازی می کنیم:./hadoop-daemon.sh start namenodeسپس برروی ماشین NameNode اول، دستور زیر را جهت اجرای ماشین های DataNode اجرا می کنیم:sudo ./start-secure-dns.shدر مرحله بعد سرویس ZooKeeper را جهت اجرای سرویس ZKFC فرمت می کنیم. دستورات زیر را برروی ماشین های برنامه ریزی شده اجرا می کنیم:./hdfs zkfc -formatZK./hadoop-daemon.sh start zkfcدر مرحله نهایی، با اجرای دستور زیر می توانیم نسبت به اطلاع از وضعیت NameNode ها و مدیریت قابلیت دسترس‌پذیری هدوپ اقدام کنیم:./hdfs haadmin -getServiceState nn1./hdfs haadmin -getServiceState nn2 ./yarn rmadmin -getServiceState rm1./yarn rmadmin -getServiceState rm2به منظور تغییر وضعیت ماشین ها از Active به Standby و برعکس به صورت دستی می توانید از دستورات زیر استفاده کنیم :./hdfs haadmin -transitionToStandby nn1 --forcemanual./hdfs haadmin -transitionToActive nn2 --forcemanualمعرفی ابزار Apache Rangerدو شرکت بزرگ حوزه کلان داده در دنیا یعنی Cloudera و Hortonworks در توزیع های نرم افزاری خود دو ابزار مهم و کاربردی به نام Apache Sentry و Apache Ranger را در حوزه امنیت زیرساخت کلان داده معرفی و پیاده سازی کردند. این دو ابزار از مهم ترین ابزارهای این حوزه می باشند. اما با ادغام این دو شرکت در سال 2019 و خرید شرکت Hortonworks توسط Cloudera باعث شد ابزار Apache Sentry به دلیل عدم اقبال مناسب در مقایسه با ابزار Apache Ranger طراحی شده توسط شرکت Hortonworks به روزرسانی نشده و ابزار Apache Ranger به دلیل فعال بودن و همینطور سهولت در استفاده و دارا بودن امکانات کامل تر، تبدیل به پروژه اصلی شرکت Cloudera شود و این ابزار را تحت لیسانس بنیاد آپاچی ارائه دهد. به گفته جامعه متخصصین کلان داده، ابزار Apache Ranger از بلوغ بیشتری نسبت به رقبای خود برخوردار می باشد.ابزار Apache Ranger یک چارچوب یکپارچه امنیتی برای پلتفرم ها و ابزارهای مبتنی بر هدوپ می باشد که از طریق ایجاد سیاست های دسترسی(Access Policy) به پایش و مدیریت دسترسی های مربوط به زیرساخت کلان داده می پردازد.این ابزار از اجزای زیر تشکیل می شود:1. Ranger Admin Portal : یک پورتال تحت وب و کاربرپسند با قابلیت REST می باشد که با استفاده از آن می توان سیاست های کاربران و سرویس ها را تعریف، پایش و مدیریت کرد. در شکل 3 و 4 تصویر ورود به پورتال و صفحه اصلی این محیط را می توانید مشاهده کنید(برای ورود به پورتال تحت وب برای اولین بار می توانید از کلمه عبور admin و رمز عبور admin استفاده کنید).2. Ranger UserSync : این ابزار برای همسان سازی کاربران موجود برروی سیستم عامل خانواده Unix و سیستم LDAP و Ranger Admin به کار می رود. همسان بودن کاربران موجود برروی Ranger Admin و سیستم عامل لینوکس از اهمیت بالایی برخوردار است که این ابزار به صورت خودکار این امکان را ایجاد می کند.3. Ranger TagSync : این ابزار برای همسان سازی برچسب های مورد استفاده در سیاست های مبتنی بر برچسب در Ranger Admin به کار می رود. این ابزار از یک منبع مشخص که می تواند یک فایل و یا یک سرویس(به طور مثال Atlas و یا Kafka) باشد برچسب ها را به Ranger Admin وارد کند. استفاده از این ابزار اجباری نیست و می توان از نصب آن صرف نظر کرد.4. Ranger KMS : این ابزار امکان مدیریت کلید در سیستم رمزنگاری داده های HDFS یا TDE را ایجاد می کند. استفاده از این ابزار اجباری نیست و می توان از نصب آن نیز صرف نظر کرد.5. Ranger Plugins : نرم افزار Apache Ranger دارای پلاگین های آماده ای می باشد که برای متصل کردن سرویس هایی مثل HDFS، YARN، Hive و... استفاده می شود. در واقع برای ایجاد امنیت در ابزارهای زیرساخت کلان داده به این پلاگین ها نیاز است.شکل 4 صفحه ورود به پورتال Rangerشکل 5 صفحه اصلی محیط تحت وب Ranger Admin1.10 آشنایی با Ranger Adminمحیط تحت وب Apache Ranger که Ranger Admin نام دارد، راهبر اصلی مدیریت و ایجاد سیاست های امنیتی در زیرساخت کلان داده می باشد. این ابزار با استفاده از تعریف سرویس های موجود برروی زیرساخت و ایجاد سیاست های دسترسی برروی هر سرویس، امنیت اجزای اصلی زیرساخت کلان داده را مهیا می کند.بخش های مختلف محیط کاربری این ابزار را در ادامه شرح خواهیم داد.1.1.10 بخش Access Managerپیش از اینکه بتوان سیاست های دسترسی کاربران را تعریف نمود می بایست اتصال بین اجزای اصلی زیرساخت کلان داده برقرار گردد. این اتصال توسط پلاگین ها یا افزونه های ارائه شده توسط Apache Ranger و نصب و پیکربندی آن انجام می شود. این بخش که نام دیگر آن Service Manager می باشد، در نسخه های قبلی با نام Repository Manager شناخته می شده است. با نصب افزونه های مربوط به هر ابزار می توان در این بخش و کلیک برروی گزینه + می توان یک سرویس را ایجاد کرد. همچنین با استفاده از گزینه های فلش پایین و فلش بالا می توان سیاست های تعریف شده به تفکیک هر سرویس را Import و یا Export کرد. این گزینه ها در سمت راست بالای صفحه هم موجود می باشند که سیاست های تعریف شده در تمامی سرویس ها را Import و Export می کند. گزینه Security Zone در بخش خودش توضیح داده خواهد شد.ابزارهای پشتیبانی شده توسط Ranger به شرح زیر می باشند:HDFSYARNHiveHBASEKnoxStormSolrKafkaNiFiKylinSqoopAtlasElasticSearchPrestoOzoneسوالی که ممکن است برای شما پیش آید این است که چرا ابزار مهم Spark در لیست وجود ندارد. آیا Ranger از این ابزار پشتیبانی نمی کند؟ پاسخ خیر است. اگرچه Ranger از این Spark به صورت رسمی پشتیبانی نمی کند اما با استفاده از پلاگین مربوط به Hive و نصب افزونه مربوطه در قسمت Hive می توان پشتیبانی از Spark SQL را در Ranger Admin برقرار نمود که در ادامه به آن خواهیم پرداخت. در شکل 5 می توانید تصویر مربوط به بخش Access Manager را که صفحه اصلی Ranger Admin است را مشاهده کنید.این بخش دارای سه زیر منو می باشد که به شرح زیر است:1. Resource Based Policies : این بخش سیاست های مبتنی بر منبع را می توان ایجاد و مدیریت نمود.2. Tag Based Policies : در این بخش سیاست های مبتنی بر برچسب را می توان ایجاد و مدیریت کرد.3. Reports : در این بخش می توان یک نگاه کلی به سیاست های تعریف شده داشت و آنها را مورد جستجو قرار داد.2.1.10 تفاوت سیاست های مبتنی بر منبع و مبتنی بر برچسبدر Ranger دو نوع سیاست گزاری وجود دارد. سیاست مبتنی بر منبع و مبتنی بر برچسب. در سیاست نوع اول، ملاک تعریف سیاست و نوع دسترسی مبتنی بر منبع است. منبع در واقع موجودیت ها در سرویس ها می باشند. به طور مثال در HDFS منابع ما فایل ها و پوشه ها هستند. در Hive منابع ما پایگاه های داده، جدول ها و ستون ها هستند. اما در مقابل سیاست های مبتنی بر برچسب، نوع منبع در آن مهم نیست و دسترسی ها توسط برچسب هایی که برای منابع تعریف شده اند صورت می پذیرد. به طور مثال اگر در دو منبع HDFS و Hive داده های حساس مربوط به گزارشات مالی مشتریان، اطلاعات پزشکی و... موجود باشند، می توان برای آنها به طور مثال برچسب Confidential تعریف کرد تا دسترسی کاربران به منابعی که برچسب دارند به شکل دیگری مدیریت شود. اینکار باعث سهولت در تعریف سیاست های خاص می شود. به طوری که دیگر نیاز نیست به صورت پراکنده سیاست های دسترسی کاربران به منابع خاص را به صورت مجزا و تک به تک ایجاد کرد. در شکل شماره 6، فلوچارت مربوط به بررسی سیاست های مبتنی بر برچسب و تقدم عملکرد آنها را می توانید مشاهده کنید.شکل 6 فلوچارت تقدم عملکرد سیاست های مبتنی بر برچسب3.1.10 بخش Auditدر بخش Audit یا بازرسی به گزارشات سرویس پرداخته می شود. این گزارشات شامل گزارشات عملیات کاربری سرویس در سربرگ Access، گزارشات مربوط به مدیریت سیاست ها در سربرگ Admin، گزارشات مربوط به ورود کاربران به Ranger Admin در سربرگ Login Sessions، گزارشات مربوط به اتصال اجزای اصلی زیرساخت کلان داده از طریق افزونه ها در سربرگ Plugins، گزارشات مربوط به وضعیت افزونه ها در سربرگ Plugin Status و گزارشات مربوط به عملیات همسان سازی کاربران توسط Ranger UserSync در سربرگ User Sync می شوند. در این بخش می توان به جستجوی گزارشات نیز پرداخت. در شکل 7 تصویر مربوط به این بخش را می توانید مشاهده نمایید.شکل 7 بخش Audit یا بازرسی4.1.10 بخش Security Zoneدر این بخش می توان به تفکیک سرویس ها و کاربران به Zone ها یا مناطق مختلف پرداخت. به معنی دیگر می توان سیاست های دسترسی را براساس Zone به صورت تفکیک شده مدیریت و ایجاد کرد. به طور مثال فرض کنید در یک سازمان، داده های اداره مالی و اداره فروش برروی زیرساخت کلان داده ذخیره سازی، مدیریت و پردازش می شود. داده های اداره مالی برروی سرویس HDFS در مسیر /finance قرارگرفته اند. همچنین برروی سرویس Hive نیز پایگاه داده ای به همین نام در اختیار این اداره می باشد. بر روی سرویس Kafka نیز Topic های ساخته شده با پیشوند FIN_ متعلق به آنها است. از طرف دیگر اداره فروش نیز داده های مخصوص به خودش با نام های دیگر را برروی زیرساخت دارد. پس در این بخش، دو Zone به نام های finance و sales تعریف می کنیم. اگر کاربر ali بخواهد به پایگاه داده متعلق به محدوده finance دسترسی یابد، سیاست های خاص تعریف شده برای این Zone خاص ترتیب اثر داده می شود. اینکار باعث مدیریت بهتر سیاست های تعریف شده، گزارشات بازرسی و همچنین تفکیک کاربران و نقش های آنها می شود. در بخش های Access Manager و Audit و انتخاب Zone موردنظر می توانیم به سیاست ها و گزارشات بازرسی خاص این Zone دسترسی یابیم. همچنین می توان کاربری با نقش Auditor یا بازرس برروی Ranger Admin ساخت که بازرسی گزارشات مخصوص به یک Zone خاص را بر عهده داشته باشد. در شکل 8 تصویر مربوط به این بخش را می توانید مشاهده کنید.شکل 8 صفحه اصلی بخش Security Zone5.1.10 بخش Settingsدر این بخش میتوان تنظیمات کاربری مربوط به Ranger Admin را مدیریت نمود. با ورود به این بخش سربرگ های Users، Groups و Roles را مشاهده خواهیم کرد. در سربرگ اول لیست کاربران مربوط به Ranger Admin و همینطور کاربرانی که میخواهیم برای آنها سیاست های امنیتی تعریف کنیم قرار می گیرد. همچنین در این سربرگ امکاناتی از قبیل ویرایش و حذف کاربر وجود دارد. در سربرگ دوم می توان گروه های کاربری را ایجاد و مدیریت نمود. در سربرگ سوم هم می توان نقش های کاربری را تعریف و مدیریت کرد. تصویر صفحه اصلی این بخش را می توانید در شکل 9 مشاهده نمایید.شکل 9 صفحه اصلی بخش Settingsادامه دارد ...به روزرسانی: بخش چهارم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.با من در بخش های دیگر این مستند همراه باشید و در صورت وجود ابهام و سوال و ارتباط با من می توانید با ایمیل من mobinranjbar1 روی جیمیل و یا لینکدین من مکاتبه کنید. مبین رنجبر مبین رنجبر Wed, 27 Aug 2025 13:59:09 +0330 https://virgool.io/bigdataengineer/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%B9%D9%85%D9%84%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D9%87%D8%A7%DB%8C-%DA%A9%D9%84%D8%A7%D9%86-%D8%AF%D8%A7%D8%AF%D9%87-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-eoynux8ish0a به روزرسانی: بخش سوم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.در بخش قبل به کلیات و اصول امنیت زیرساخت های کلان داده و بررسی راهکارهای اولیه پرداخته شد. در این بخش نگاه عمیق تری به راه حل های موجود خواهیم داشت و در عمل آنها را بررسی خواهیم کرد.توجه: اگر بخش قبل را مطالعه نکردید، به این لینک مراجعه کنید.نصب و راه اندازی Kerberosبه منظور نصب و راه اندازی مکانیزم امنیتی Kerberos می بایست ماشین سرور یا همان KDC و سرویس گیرندگان به کتابخانه و نرم افزار آن مجهز شوند. سیستم عامل انتخابی ما برای نصب CentOS نسخه 7 و Kerberos نسخه 5 می باشد.در ابتدا می بایست همه ماشین های یک قلمرو یا Realm دارای یک نام میزبان مشابه باشند تا بتوانند در Realm اضافه شوند. نام میزبان در هنگام نصب سیستم عامل از کاربر دریافت می شود. اگر اینکار را انجام نداده اید می توانید با اجرای دستور زیر در ترمینال سیستم عامل، نام میزبان ماشین ها را تغییر دهید:sudo hostnamectl set-hostname test.comهمچنین در فایل /etc/hosts سیستم عامل می بایست تمامی ماشین ها حاوی نام میزبان خود باشند. با استفاده از ویرایشگرهای متنی این فایل را برای ویرایش باز کنید و به صورت زیر تغییر دهید:192.168.1.1 masternode test.com192.168.1.2 slavenode1 test.com192.168.1.3 slavenode2 test.comاینکار باعث می شود اگر کاربر بخواهد برروی هرکدام از ماشین های کلاستر، عملیات کاربری مربوط به زیرساخت کلان داده را انجام دهد با مشکل مواجه نشود(علت مشکلی که کاربر با آن مواجه می شود را در ادامه توضیح خواهیم داد).حال نوبت به نصب اجزای اصلی می رسد. برروی ماشینی که نقش سرور Kerberos را بر عهده دارد(در اینجا همان ماشین masternode) دستورات زیر را جهت نصب نرم افزار سرور و کتابخانه های کاربری Kerberos برروی ترمینال سیستم عامل اجرا می کنیم:sudo yum install krb5-serversudo yum install krb5-workstationبرروی ماشین های سرویس گیرنده و یا فرعی فقط کافی است با استفاده از دستور زیر نرم افزار مربوط به کتابخانه های کاربری نصب شود:sudo yum install krb5-workstationبعد از نصب نرم افزارها، نوبت به اعمال تنظیمات می رسد. در مسیر /var/Kerberos/krb5kdc فایل kdc.conf را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و در بخش realms نام قلمرو(در اینجا به طور مثال TEST.COM) را منحصرا با حروف بزرگ وارد کنید. به صورت زیر:[realms] TEST.COM = {….}با انجام اینکار تنظیمات خاص مربوط به قلمرو موردنظر ما در KDC تعریف می شود. نوشتن نام قلمرو با حروف بزرگ قراردادی است که توسط توسعه دهندگان آن تعیین شده است و می بایست رعایت شود.سپس فایل تنظیمات مربوطه را ذخیره می کنیم. نمای کلی این فایل پس از ویرایش به صورت زیر خواهد بود:[kdcdefaults] kdc_ports = 88 kdc_tcp_ports = 88[realms]TEST.COM = { #master_key_type = aes256-cts acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal }پس از انجام اینکار، فایل تنظیمات کاربری Kerberos به نام krb5.conf در مسیر /etc را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و تغییرات زیر را اعمال کنید:الف) در بخش libdefaults مقدار default_ccache_name را با قراردادن علامت شارپ(#) در ابتدای آن کامنت کنید(علت اینکار عدم شناسایی مسیر موقت ذخیره سازی TGT در برخی از نسخه های نرم افزارهای کلان داده می باشد. با انجام اینکار به Kerberos میگوییم اطلاعات مربوط به بلیط های کاربری را در مسیر موقت سیستم عامل یعنی /tmp ذخیره کن).ب) در بخش قبلی مقدار default_realm را برابر با نام قلمرو تعیین شده(در اینجا TEST.COM) با حروف بزرگ قرار دهید(علت اینکار این است که همواره برای سهولت در ایجاد Principal ها و به طور کل انجام عملیات مربوط به Kerberos نیازی که ذکر نام قلمرو نیست و این مقدار مورد استفاده قرار میگیرد).ج) در بخش realms نام قلمرو به همراه آدرس های میزبان مربوط به KDC و Admin Server را تغییر دهید. به صورت زیر:TEST.COM = { kdc = masternode:88 admin_server = masternode }در تنظیمات بالا نقش KDC را ماشین سرور(در اینجا masternode) بازی می کند و قراردادن شماره پورت پیش فرض این سرویس که 88 است در انتهای نام میزبان ضروری می باشد. همچنین در این بخش می بایست نام میزبان ماشین مربوط به Admin Server را وارد کنید. در مثال ما سرویس های KDC و Admin Server بر روی یک ماشین قرار دارند(سرویس Admin Server همان Kadmin می باشد که نقش پایگاه داده Kerberos را بازی می کند. در ادامه نقش این پایگاه داده را توضیح خواهیم داد).د) در بخش domain_realm مقادیر مربوط به فضای نام قلمرو را به صورت زیر تغییر می دهیم:.test.com = TEST.COM test.com = TEST.COMاینکار باعث می شود تا اگر کاربری نام قلمرو و همچنین زیردامنه های قلمرو را به صورت حروف کوچک مورد استفاده قرار داد، مشکلی در روند کار بوجود نیاید و به حروف بزرگ برگردان شود.در نهایت فایل تنظیمات را ذخیره می کنیم و این تغییرات را برروی تمامی ماشین های کلاستر تکرار می کنیم. نمای کلی این فایل پس از ویرایش به صورت زیر است:includedir /etc/krb5.conf.d/[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log[libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt default_tkt_enctypes = aes256-cts-hmac-sha1-96 arcfour-hmac des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes256-cts-hmac-sha1-96 arcfour-hmac des-cbc-md5 des-cbc-crc permitted_enctypes = aes256-cts-hmac-sha1-96 arcfour-hmac des-cbc-md5 des-cbc-crc default_realm = TEST.COM# default_ccache_name = KEYRING:persistent:%{uid}[realms] MOBINRANJBAR.COM = { kdc = masternode:88 admin_server = masternode }[domain_realm] .test.com = TEST.COM test.com = TEST.COMدر مرحله بعد، می بایست قلمرو تعریف شده در تنظیمات را در پایگاه داده ایجاد کنیم و دستور زیر را برای اینکار اجرا کنیم:kdb5_util create -r TEST.COM -sدر اجرای دستور بالا ممکن است با خطای دسترسی مواجه شوید که می توان با قرار دادن sudo در ابتدای دستور این مشکل را برطرف کرد. با اجرای دستور بالا برای اولین بار، کلمه عبور اصلی مربوط به پایگاه داده از کاربر درخواست می شود که می بایست یک کلمه عبور دلخواه وارد شود. این کلمه عبور برای کار با Kadmin و همچنین دسترسی KDC به پایگاه داده ضروری است.پارامترهای r و s به ترتیب برای تعیین نام قلمرو و ذخیره سازی کلمه عبور اصلی پایگاه داده در فایل stash می باشد(فایل stash یک فایل محلی حاوی کلمه عبور کد شده می باشد. این فایل هنگام اجرای سرویس های krb5kdc و kadmind جهت اعلام کلمه عبور پایگاه داده به کار می رود).پس از انجام اینکار، حال می بایست به سرویس kadmin اعلام کنیم که قلمرویی که می بایست برروی آن فعالیت کند چیست. برای اینکار فایل kadm5.acl را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید و مقدار زیر را وارد کنید:*/admin@TEST.COM *سپس فایل موردنظر را ذخیره کنید.پس از انجام تنظیمات اولیه، می بایست سرویس های kadmin مربوط به Admin Server و krb5kdc مربوط به KDC را راه اندازی کنیم. با دستورات زیر این سرویس ها را راه اندازی می کنیم:sudo service krb5kdc startsudo service kadmin startبا اجرای دستورات بالا سرویس های اصلی Kerberos راه اندازی می شود. نکته ای که می بایست دقت کنید این است که این سرویس ها هنگام راه اندازی مجدد سرور و یا خاموش شدن ناگهانی آن مجددا راه اندازی نمی شود. برای اجرای این سرویس ها هنگام راه اندازی سیستم عامل کافی است دستورات زیر را اجرا نمایید:sudo chkconfig krb5kdc onsudo chkconfig kadmin onشروع کار با Kerberosپس از نصب موفقیت آمیز Kerberos در این بخش به چگونگی انجام عملیات کاربری متداول می پردازیم. اولین کاری که پس از نصب عموما انجام می گیرد، تعریف Principal هم در محیط مدیریتی Kerberos یا همان kadmin است. برای اینکار برروی سروری که عنوان Admin Server است دستور زیر را وارد کنید تا به این محیط وارد شوید.sudo kadmin.localدستورات کاربری پرکاربرد این محیط در جدول 1 قرار داده شده است.جدول 1بسته کاربری Kerberos نیز شامل دستورات پرکاربردی می شود که در زیر آنها را معرفی می کنیم:1. دستور Kinit : وظیفه این دستور نگهداری و کش کردن بلیط برای یک Principal خاص می باشد. با اجرای این دستور در محیط ترمینال به این معنی است، کاربری که هویت خود را احراز کرده است اجازه اجرای عملیات سرویس موردنظر برروی این ترمینال را دارا می باشد. در واقع این دستور هم وظیفه احراز هویت و هم اعطای مجوز را بر عهده دارد. از نگاه دیگر، این دستور را می توان مترادف عملیات login دانست.2. دستور Klist : این دستور بلیط های مربوط به یک Principal خاص موجود برروی حافظه موقت و یا کلیدهای موجود برروی یک فایل keytab را لیست می کند. به طور کل با اجرای این دستور می توان بررسی کرد آیا کاربر احراز هویت شده و دارای مجوز یا بلیط می باشد یا خیر.3. دستور kdestroy : با اجرای این دستور تمامی بلیط های موجود برروی حافظه موقت حذف می شوند. این دستور مترادف عملیات logout در سیستم های متداول می باشد.برای درک دقیق تر عملیات شرح داده شده در بالا، اجازه دهید یک مثال کامل را پیاده سازی کنیم.فرض کنید میخواهیم کاربری به نام hduser را احراز هویت کنیم و به او اجازه دهیم سرویس موردنظر خود را اجرا کند. مرحله احراز هویت به دو صورت می تواند انجام گیرد. کاربر با استفاده از رمزعبور خود به سیستم عامل وارد می شود اما کاربر یا سرویس تعریف شده برروی Kerberos هم دارای یک رمزعبور است. این رمز با رمزعبور کاربر برروی سیستم عامل چه تفاوتی دارد؟ فرض کنید کاربر موردنظر، یک کاربر اشتراکی است. به این معنی که این کاربر احراز هویت سیستمی شده است اما مشخص نیست برای کدام سرویس ها احراز هویت شده است. کاری که دستور kinit انجام می دهد این است که در هنگام ورود و یا احراز هویت عملیات اعطای مجوز نیز انجام می گیرد. حال فرض کنید کاربر موردنظر اجازه استفاده از سرویس های خاص را نداشته باشد. طبیعتا رمزعبور احراز هویت در آن سرویس را نخواهد داشت.همچنین، عملیات احراز هویت و اعطای مجوز را می توان با استفاده از یک فایل کلید با پسوند .keytab نیز انجام داد. به اینصورت که دیگر نیازی به اعلام رمزعبور نمی باشد و فایل کلید موردنظر حاوی رمز کدشده کاربر می باشد. مزیت اینکار در این است که برای اجرای سرویس ها و نرم افزارهای مختلف می توان کاربر را به صورت خودکار احراز هویت نمود.برای انجام این مثال فرض می کنیم که کاربر hduser برروی سیستم عامل تعریف شده است و دارای رمزعبور مخصوص به خود می باشد. این کاربر یک SPN برروی Kerberos می باشد. به این معنی که نقشی در سرویس خاصی ندارد و یک کاربر معمولی است.مرحله اول تعریف کاربر موردنظر در kadmin می باشد. با دستور زیر با محیط موردنظر وارد می شویم:sudo kadmin.localسپس با استفاده از دستور زیر Principal مخصوص به این کاربر را اضافه می کنیم. دستور زیر را در اعلان محیط kadmin وارد می کنیم:addprinc hduser@TEST.COMبا اجرای دستور بالا، رمزعبور دلخواه برای این کاربر درخواست می شود که در هنگام احراز هویت می توان از این رمز استفاده کرد. شکل دیگر دستور بالا به صورت است که در هنگام ساخت فایل کلید keytab مورد استفاده قرار میگیرد و دیگر نیازی به وارد کردن رمزعبور دلخواه نیست:addprinc -randkey hduser@TEST.COMپارامتر -randkey به kadmin اعلام می کند که رمزعبور را به صورت تصادفی و کدشده تولید کند.در شکل اول اجرای این دستور، نیازی به انجام عملیات دیگری نمی باشد و با اجرای دستور زیر از محیط kadmin خارج شوید:exitامام در شکل دوم اجرای دستور بالا، به دلیل اینکه کاربر موردنظر از رمز عبور خود اطلاع ندارد و یا یک کاربر سرویس است می بایست فایل کلید رمز را تولید کنیم. با دستور زیر می توان فایل کلید مربوط به کاربر خاص را در محیط kadmin تولید کرد:xst -kt /home/myuser/hduser.keytab hduser@TEST.COMبا اجرای دستور بالا در مسیر /home/myuser/ فایل کلید به نام hduser.keytab ساخته می شود که این فایل بیانگر رمزعبور کاربر موردنظر می باشد که قاعدتا می بایست از این فایل محافظت شود. نکته مهم در استفاده از این فایل این است که مالک یا owner فایل کلید می بایست همان کاربری باشد که از آن استفاده می کند و پیشنهاد می شود دسترسی کد 400 را به صورت زیر به فایل کلید نسبت دهید:chmod 400 /home/myuser/hduser.keytabپس از انجام اینکار، کاربر موردنظر در محیط کاربری خود کافی است دستور زیر را اجرا کند و رمزعبور خود را وارد کند:kinit hduser@TEST.COMاگر دستور بالا با موفقیت اجرا شود هیچ پیامی در خروجی چاپ نمی شود و نتیجه را می توان با اجرای دستور klist مشاهده کرد. خروجی نمونه این دستور به صورت زیر می باشد:Ticket cache: FILE:/tmp/krb5cc_1001Default principal: hduser@TEST.COM Valid starting Expires Service principal2020-03-26T13:24:47 2020-03-27T13:24:47 krbtgt/TEST.COM@TEST.COMبا اجرای دستورات بالا، کاربر موردنظر با موفقیت احراز هویت شده است و می تواند از سرویس موردنظر استفاده کند. شاید این سوال برای شما ایجاد شده باشد که این بلیط تا چه زمانی معتبر می باشد؟اتفاقاتی که برای بلیط می تواند رخ دهد به صورت زیر است:1. حذف بلیط از طریق اجرای kdestroy : با استفاده از دستور kdestroy می توان تمامی بلیط های معتبر را از حافظه موقت حذف کرد.2. سررسید تاریخ اعتبار بلیط: هر Principal در Kerberos دارای تاریخ انقضا می باشد که در هنگام ساخت می توان آنرا مشخص نمود. اگر این تاریخ به سر رسد، بلیط از درجه اعتبار ساقط می شود. با اجرای دستور زیر می توان در هنگام ساخت Principal تاریخ انقضا را تعیین کرد:addprinc hduser -expire "1/1/2020 12:01am EST"3. سررسید عمر بلیط: مشابه تاریخ اعتبار بلیط، هر Principal در Kerberos دارای یک عمر تعیین شده هستند که این زمان می تواند محدود و یا نامحدود باشد. به صورت پیش فرض این مقدار برروی 1 روز تنظیم شده است. این مقدار را می توان از طریق مقدار ticket_lifetime در فایل تنظیمات kdc.conf در مسیر /var/Kerberos/krb5kdc تنظیم کرد. البته برای هر بلیط هم می توان این مقدار را قائل بود و اگر این مقدار در هنگام ساخت Principal تعیین نگردد، مقدار پیش فرض انتخاب می شود. در هنگام ساختPrincipal می توان به صورت زیر عمر بلیط را تعیین کرد:addprinc hduser -maxlife "5 days"برای انجام عملیات kinit از طریق فایل کلید می توان به صورت زیر اقدام کرد:kinit -kt /home/myuser/hduser.keytab hduser@TEST.COMپیکربندی هدوپ و فعال سازی Kerberos در آنبه منظور پیکربندی هدوپ و Kerberos می بایست مرحله ابتدایی فاز نصب و راه اندازی Kerberos که همان تنظیم فایل /etc/hosts است انجام گیرد تا ماشین های اصلی و فرعی مشخص شوند. پس از انجام اینکار. می بایست کاربران و گروه کاربری سرویس ها برروی تمامی ماشین ها ساخته شوند. نقشه کاربران موردنیاز هدوپ را می توانید در جدول 2 مشاهده کنید.جدول 2با استفاده از دستورات زیر می توان کاربران و گروه کاربری موردنظر را در ماشین های در اختیار هدوپ ایجاد کرد:sudo groupadd hadoop sudo useradd -g hadoop hdfs sudo passwd hdfs sudo useradd -g hadoop mapred sudo passwd mapred sudo useradd -g hadoop yarn sudo passwd yarn sudo useradd -g hadoop http sudo passwd httpدر خط شماره 1، گروه کاربری Hadoop ساخته شد و کاربران موردنیاز در جدول 2 به ترتیب در خطوط بعدی ساخته شدند و رمزعبور هرکدام تنظیم شد..نکته قابل توجه در این بخش این است که کاربران اصلی مثل hdfs و yarn می بایست دارای دسترسی مدیر باشند. به این معنی که قابلیت اجرای sudo را داشته باشند. علت آن را در ادامه توضیح خواهیم داد.در مرحله بعد، با استفاده از دستور زیر می بایست به محیط ترمینال کاربر hdfs وارد شوید. برای اینکار می توانید از دستور زیر استفاده کنید:su hdfsدر هنگام راه اندازی سرویس های هدوپ، رمزعبور مربوط به کاربر به صورت مکرر از کاربر دریافت می شود و ممکن است در روند اجرای سرویس باعث اختلال شود. با استفاده از دستورات زیر و اجرای آنها در همه ماشین ها می توانیم کاربر راه دور را به سیستمی که قصد اجرای سرویس های هدوپ را دارد معرفی کنیم:ssh-keygen -t rsa ssh-copy-id -i ~/.ssh/id_rsa.pub hdfs@masternode ssh-copy-id -i ~/.ssh/id_rsa.pub hdfs@slavenode1 ssh-copy-id -i ~/.ssh/id_rsa.pub hdfs@slavenode2 chmod 0600 ~/.ssh/authorized_keysبه تعداد ماشین های موجود در کلاستر خط شماره 3 و 4 تکرار می شود.در مرحله بعد می بایست بسته هدوپ را دانلود و استخراج کنید. در این سند از نسخه هدوپ 2.10.0 استفاده خواهیم کرد. نکته قابل توجه در این مرحله این است که زمانیکه هدوپ به صورت چندکاربره و امنیت کامل راه اندازی می شود می بایست در یک مسیر مشخص در سیستم عامل قرار گیرد. پس بسته فشرده هدوپ را در مسیر عمومی مانند /usr/share قرار می دهیم و مالک پوشه هدوپ و تمامی زیرفایل ها و پوشه های آن را از طریق دستور زیر به کاربر hdfs تغییر می دهیم:sudo chown -R hdfs:hadoop /usr/share/hadoopهمچنین می بایست مسیر مربوط به ذخیره سازی ابرداده ها و داده ها را بسازید. در مسیر /usr/share یک پوشه دلخواه به طور مثال به نام hadoopstorage بسازید و در این پوشه، در ماشین اصلی یا NameNode پوشه name و در ماشین فرعی یا DataNode پوشه data را ایجاد کنید. پس از انجام اینکار با اجرای دستور بالا و تغییر مسیر پوشه به hadoopstorage مالک این پوشه را نیز به hdfs تغییر دهید.پس از انجام اینکار نیاز به پیکربندی JCE و JSVC می باشد که در روند پیکربندی هدوپ بسیار حائز اهمیت می باشد. JCE در واقع یک بسته کتابخانه حاوی دو فایل اجرایی در جاوا می باشد که شامل استانداردهای قابل قبول جهت رمزنگاری و رمزگشایی در شبکه توسط سازندگان جاوا می شود. به دلیل استفاده Kerberos از الگوریتم ها و استاندارد های رمزنگاری و رمزگشایی مانند AES256 در صورت عدم وجود این کتابخانه، نرم افزارهایی که مبتنی بر جاوا هستند نظیر هدوپ را با مشکل مواجه می کند. نرم افزار JSVC نیز یک فایل اجرایی می باشد که جهت انجام ارتباط امن بین ماشین های فرعی یا DataNode ها مورد استفاده قرار می گیرد که در صورت عدم وجود این فایل اجرایی، نصب و راه اندازی هدوپ با خطا مواجه می شود.به منظور پیکربندی JCE ابتدا می بایست بسته موردنظر را از سایت اوراکل جاوا دانلود کنید. پس از دانلود دو فایل موجود در این بسته با نام های local_policy.jar و US_export_policy.jar را در مسیر $JAVA_HOME/jre/lib/security کپی کنید. اگر این فایل ها موجود هستند آنها را با جدیدترین نسخه جایگزین نمایید. پس از آن فایل java.security در همان مسیر را با یکی از ویرایشگرهای متنی برای ویرایش باز کنید. در این فایل مقدار crypto.policy را پیدا کنید و به صورت زیر از حالت کامنت خارج کنید:crypto.policy=unlimitedپس از انجام اینکار فایل با ذخیره کنید.در مرحله بعد بسته سورس کد commons-daemon که حاوی کدهای فایل اجرایی jsvc است را از این لینک دانلود و سپس با دستورات زیر آنرا کامپایل می کنیم. این بسته به صورت دودویی و اجرایی نیز وجود دارد اما به دلیل اینکه حاوی فایل اجرایی jsvc نمی باشد و این فایل فقط در فرآیند کامپایل سورس کد اصلی ساخته می شود از استفاده از این بسته خودداری می کنیم. بسته موردنظر را استخراج کرده و وارد پوشه src/native/unix می شویم. به صورت زیر دستورات را اجرا می کنیم:./configure makeپس از اجرای موفقیت آمیز دستورات بالا، فایل اجرایی jsvc به همین نام در مسیر جاری ایجاد می شود. این فایل را در مسیر $HADOOP_HOME/sbin کپی کنید.به منظور اعطای مجوز و احراز هویت کاربر سرویس هدوپ، می بایست کاربران موردنظر را در kadmin تعریف و فایل کلیدهای آنان را پس از تولید در مسیر تنظیمات هدوپ قرار دهید. برای ساخت Principal ها و تولید فایل های کلید مخصوص به آنها دستورات زیر را در kadmin وارد می کنیم:addprinc -randkey hdfs/masternode addprinc -randkey mapred/masternode addprinc -randkey yarn/masternode addprinc -randkey HTTP/masternode xst -kt /home/hdfs/hdfs.keytab hdfs/masternode xst -kt /home/hdfs/mapred.keytab mapred/masternode xst -kt /home/hdfs/yarn.keytab yarn/masternode xst -kt /home/hdfs/http.keytab HTTP/masternodeپس از انجام دستورات بالا، فایل های کلید ساخته شده را در مسیر ذکر شده در بالا منتقل و طبق مثال مطرح شده در بخش نصب و راه اندازی Kerberos دسترسی های موردنظر را تنظیم نمایید. لازم به ذکر است فایل کلیدهای ساخته شده می بایست در همه ماشین ها کپی شوند و وجود آنها در تمامی ماشین ها الزامی است. به سراغ اعمال تنظیمات هدوپ می رویم. برای شروع از ماشین اصلی یا NameNode شروع می کنیم. تنظیمات مربوط به هدوپ در پوشه /etc/Hadoop قرار گرفته اند. ابتدا نیاز است تا نام ماشین های فرعی در فایلی به نام slaves قرار گیرد. فایل slaves در این پوشه را با یکی از ویرایشگرهای متنی باز کنید و به صورت خط به خط نام ماشین های فرعی را به صورت زیر در آن وارد کنید و سپس فایل را ذخیره کنید:slavenode1slavenode2فایل بعدی جهت اعمال تنظیمات، فایلی به نام hadoop-env.sh است که تنظیمات مربوط به متغیرهای محیطی در آن قرار میگیرد. مقدادیری که می بایست تغییر کنند به قرار زیر هستند:1. مقدار JAVA_HOME را از حالت کامنت خارج کرده و مسیر نصب شده jdk را به صورت زیر وارد نمایید:export JAVA_HOME=/usr/lib/jvm/jdk1.82. مقدار JSVC_HOME را از حالت کامنت خارج کرده و مسیر مربوط به فایل اجرایی JSVC که همان sbin هست را به صورت زیر وارد نمایید:export JSVC_HOME=/usr/share/hadoop/sbin3. مقدار HADOOP_SECURE_DN_USER را از حالت کامنت خارج کرده و نام کاربر سرویسی(در اینجا hdfs) که برروی ماشین های فرعی وظیفه اجرای سرویس را دارد را وارد کنید:export HADOOP_SECURE_DN_USER=hdfsفایل موردنظر را ذخیره کنید.در مرحله بعد به سراغ فایل core-site.xml می رویم. این فایل را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.مقدار مربوط به خط 3 جهت تعریف آدرس و شماره پورت NameNode می باشد. خطوط شماره 7 و 11 نیز جهت فعال سازی امنیت در هدوپ می باشد.پس از انجام این مرحله، فایل hdfs-site.xml را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.مقدار تعریف شده در خط شماره 3 مربوط به تعیین مسیر ذخیره سازی ابرداده ها در ماشین اصلی می باشد. در خط شماره 7 مقدار فاکتور کپی سازی بلوک ها تعریف شده است. همچنین خط شماره 11 به منظور فعال سازی قابلیت Access Token برای تبادل توکن های دسترسی بین ماشین های فرعی می باشد. در خطوط شماره 15 تا 46 به تعریف Principal ها و آدرس فایل کلیدهای مربوط به سرویس های هدوپ پرداختیم. در خطوط 47، 51 و 55 به ترتیب امکان بررسی نام آدرس و IP در NameNode، فعال سازی قابلیت استفاده DataNode ها از نام میزبان و فعال سازی مکانیزم ACL را اعمال می کنیم.در مرحله بعد فایل mapred-site.xml.templace را از طریق دستور زیر به mapred-site.xml تغییر نام دهید:mv mapred-site.xml.templace mapred-site.xmlسپس آنرا با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.در خط شماره 3 به هدوپ اعلام می کنیم که فرقی بین نسخه 1 و 2 هدوپ قائل نیستیم و همواره چارچوب مربوط به اجرای برنامه های ساختار MapReduce را برابر با YARN قرار می دهیم.در مرحله بعد فایل yarn-site.xml را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.در خط شماره 3 به YARN اعلام می کنیم که نام میزبان مربوط به سرویس ResourceManager چیست. در خط شماره 7 اعلام می کنیم که روش کار عملیات مربوط به Recovery در NodeManager برای اجرای مجدد این سرویس چیست. مقادیر تعریف شده در خطوط شماره 10 تا 17 نیز مربوط به تعریف Principal ها و آدرس قرارگیری فایل کلیدهای سرویس های YARN می شود.در مرحله بعد به سراغ ماشین های فرعی یا DataNode می رویم. فایل های slaves، Hadoop-env.sh، core-site.xml و mapred-site.xml مشابه فایل های موجود برروی ماشین NameNode می باشد و کافی است آنها را کپی کنید.در ماشین DataNode به سراغ فایل hdfs-site.xml بروید و این فایل را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.مقادیر فایل بالا تقریبا مشابه فایل موردنظر در ماشین NameNode است با این تفاوت که در خط شماره 3 مسیر مربوط به ذخیره سازی داده ها قرار می گیرد. همچنین خطوط شماره 10 تا 33 مقادیر مربوط به تعیین Principal ها و مسیر قرارگیری فایل کلیدهای مربوط به NameNode و DataNode می باشند. در خطوط شماره 35 و 39 دو مقدار جدید تعریف شده است که برای تعریف شماره پورت های DataNode می باشند. علت تغییر مقادیر پیش فرض این دو مقدار این است که برای استفاده از شماره پورت های بالای 1024 در سیستم عامل دسترسی های خاصی نیاز است که DataNode در هنگام تصاحب این شماره پورت ها دارای مشکل می شود و به صورت پیش فرض نیز برروی این شماره پورت ها تنظیم شده است. به همین منظور این شماره پورت ها را به دلخواه زیر 1024 مقداردهی می کنیم.فایل بعدی جهت تنظیم در ماشین DataNode فایل yarn-site.xml می باشد. این فایل را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر مربوط به فایل موردنظر در مخزن گیت هاب این مستند را قرار دهید.مقادیر مربوط به فایل بالا، مشابه فایل موجود برروی ماشین NameNode می باشد ولی با این تفاوت که مقادیر مربوط به تعیین Principal ها و مسیر قرارگیری فایل کلیدهای مخصوص به ماشین NodeManager نیز به آن اضافه می شود.عملیات موردنظر را در تمامی ماشین های DataNode دیگر تکرار می کنیم.پس از انجام تنظیمات مربوطه، برای اولین بار می بایست NameNode را فرمت کنیم. برای انجام اینکار به مسیر bin از پوشه هدوپ بروید و دستور زیر را اجرا کنید:./hadoop namenode -format با اجرای موفقیت آمیز دستور بالا، پیغام زیر نمایش می یابد:Storage directory XXXX has been successfully formatted. مرحله بعد می بایست سرویس های اصلی HDFS را راه اندازی کنیم.دقت کنید که ابتدا سرویس HDFS را اجرا می کنیم و اجرای سرویس YARN نیازمند تنظیمات بیشتری می باشد که در ادامه توضیح خواهیم داد.پیش از اجرای سرویس، کاربر سرویس یعنی hdfs جهت راه اندازی می بایست احراز هویت شود. برای اینکار کافی است دستور زیر را وارد نمایید:kinit -kt /usr/share/hadoop/etc/hadoop/hdfs.keytab hdfs/masternodeبرای اجرای سرویس HDFS پوشه جاری را به مسیر $HADOOP_HOME/sbin تغییر داده و دو دستور زیر را اجرا نمایید:./start-dfs.shsudo ./start-secure-dns.shدر خط شماره 1 سرویس های NameNode و SecondaryNameNode راه اندازی می شوند ولی سرویس های DataNode برروی ماشین های خود راه اندازی نمی شوند. در خط شماره 2 سرویس های DataNode را با استفاده از فایل اسکریپت start-secure-dns.sh و دسترسی sudo اجرا می کنیم. علت آن این است که برخی از شماره پورت هایی که DataNode به آن نیاز دارد نیاز به دسترسی مدیر دارند و به همین علت با دستور sudo آنرا اجرا می کنیم.پس از انجام دستورات بالا، با اجرای دستور jps از راه اندازی موفقیت آمیز سرویس های موردنظر اطمینان حاصل کنید. دقت کنید که خروجی این دستور برای هر کاربر متفاوت است و فقط می تواند سرویس های جاوایی که توسط کاربر جاری اجرا شده است را نمایش دهد. نکته دیگری که خوب است بدانید، زمانی که هدوپ را به صورت امن راه اندازی می کنید نام Process یا پردازه مربوط به DataNode به Secur تغییر پیدا می کند.در مرحله بعد، به تنظیم سرویس YARN می پردازیم. تنظیمات مربوط به پیکربندی YARN تا حد زیادی در مراحل قبل انجام شده است و در ادامه به نکات پیکربندی کامل این سرویس می پردازیم.در ابتدا همانند سرویس HDFS می بایست به محیط ترمینال کاربر yarn وارد شوید. برای اینکار می توانید از دستور زیر استفاده کنید:su yarnفرض می کنیم که کاربر yarn دارای دسترسی sudo می باشد. به دلیل اینکه مالک پوشه هدوپ کاربر hdfs است، برخی فایل ها و پوشه می بایست مالک آن به کاربر yarn تغییر کند. اولین فایلی که می بایست مالک آن تغییر کند، فایل کلید مربوط به کاربر سرویس yarn است. با استفاده از دستور زیر مالک آنرا به yarn تغییر دهید:sudo chown yarn:hadoop /usr/share/hadoop/etc/hadoop/yarn.keytabبه دلیل آنکه پوشه مربوط به ذخیره سازی گزارشات هدوپ یعنی logs در اختیار کاربر hdfs است و سرویس YARN نمی تواند گزارشات خود را در این پوشه ذخیره کند با خطا مواجه خواهد شد. برای این منظور یک پوشه به نام yarn و درون آن پوشه ای به نام logs می سازیم و مالک آنرا به کاربر yarn تغییر می دهیم. در مرحله بعد می بایست مسیر این پوشه را به سرویس YARN معرفی کنیم. خط زیر را در فایل .bashrc مربوط به کاربر yarn که در مسیر /home/yarn/.bashrc قرار دارد وارد می کنیم و فایل را ذخیره می کنیم:export YARN_LOG_DIR=”/usr/share/hadoop/logs/yarn/logs”سرویس YARN برای ایجاد Container برروی ماشین های فرعی یا NodeManager از فایل اجرایی container-executor در مسیر bin و فایل تنظیمات مربوط به آن به نام container-executor.cfg در مسیر etc/Hadoop استفاده می کند. هدوپ جهت ایجاد Container برای اجرای برنامه های کاربران از کاربر root برای اینکار استفاده می کند. به همین علت دسترسی این 2 فایل می بایست بین کاربر root و کاربران گروه Hadoop مشترک باشد. به منظور سهولت در تعیین دسترسی موردنیاز، این 2 فایل را در پوشه ای جداگانه به نام دلخواه hadoop-yarn در مسیر /usr/share قرار می دهیم و دستورات زیر را جهت ایجاد پوشه های موردنیاز اجرا می کنیم:sudo mkdir /usr/share/hadoop-yarn sudo mkdir /usr/share/hadoop-yarn/bin sudo mkdir /usr/share/hadoop-yarn/etc sudo mkdir /usr/share/hadoop-yarn/etc/hadoopپوشه های موردنیاز را با استفاده از دستورات بالا با دسترسی root در مسیر موردنظر ایجاد کردیم. سپس 2 فایل ذکر شده در بالا را در مسیرهای ساخته شده کپی می کنیم. به صورت زیر:sudo cp /usr/share/hadoop/bin/container-executor /usr/share/hadoop-yarn/bin sudo cp /usr/share/Hadoop/etc/hadoop/container-executor.cfg /usr/share/hadoop-yarn/etc/hadoopپس از کپی فایل ها، فایل مربوط به تنظیمات یعنی container-executor.cfg را با یکی از ویرایشگرهای متنی جهت ویرایش باز کنید و مقادیر موجود را به صورت زیر تغییر دهید:yarn.nodemanager.linux-container-executor.group=hadoopbanned.users=min.user.id=500allowed.system.users=feature.tc.enabled=0خط شماره 1 در بالا گروه کاربری مربوط به اجرای Container را تعیین می کند. در خطوط شماره 2 و 4 می توان تعیین کرد که چه کاربرانی اجازه اجرای Container را دارند و چه کاربرانی ندارند. خط شماره 3 کد شروع شناسه کاربران غیرسیستمی را تعیین می کند. در توزیع Centos این مقدار برابر با 500 و در توزیع های دیگر برابر با 1000 می باشد. در خط شماره 5 هم فعال یا غیرفعال بودن قابلیت TrafficControl تنظیم می شود. این قابلیت در NodeManager باعث می شود که این سرویس بتواند ترافیک مربوط در شبکه در ماشین های NodeManager را کنترل کند. فعال سازی آن در این بخش لازم نمی باشد.در مرحله بعد، دسترسی های مربوط به این 2 فایل را با استفاده از دستورات بالا اعمال می کنیم:sudo chown root:hadoop /usr/share/hadoop-yarn/bin/container-exeuctor sudo chmod 6050 /usr/share/hadoop-yarn/bin/container-exeuctor sudo chown root:hadoop /usr/share/hadoop-yarn/etc/hadoop/container-executor.cfg sudo chmod 440 /usr/share/hadoop-yarn/etc/hadoop/container-executor.cfgسرویس YARN جهت راه اندازی امن نیاز به کتابخانه های Protoc دارد که در بسته هدوپ موجود می باشد. برای معرفی مسیر این فایل های کتابخانه، در فایل .bashrc مربوط به کاربر yarn که در مسیر /home/yarn/.bashrc قرار دارد مقدار زیر را اضافه کنید:export HADOOP_PROTOC_PATH=/usr/share/hadoop/share/hadoop/yarn/libپیکربندی های انجام شده را در تمامی ماشین های NodeManager اعمال کنید و سپس از طریق کاربر yarn به ماشین NameNode و پوشه $HADOOP_HOME/sbin وارد شوید. قبل از راه اندازی سرویس های YARN می بایست کاربر yarn را احراز هویت کنید. مانند کاری که برای کاربر hdfs انجام دادیم، دستور زیر را برای این کاربر نیز اجرا نمایید:kinit -kt /usr/share/hadoop/etc/hadoop/yarn.keytab yarn/masternodeپس از انجام عملیات بالا، به پوشه sbin رفته و دستور زیر را جهت راه اندازی سرویس های YARN یعنی ResourceManager و NodeManager اجرا کنید:./start-yarn.shادامه دارد ...فکر میکنم این بخش قدری طولانی شد اما هدف این هست تا شما تجربه واقعی و عملی از اقدامات داشته باشید و از کلی گویی پرهیز شود.به روزرسانی: بخش سوم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.همچنان با من در بخش های دیگر این مستند همراه باشید و در صورت وجود ابهام و سوال و ارتباط با من می توانید با ایمیل من mobinranjbar1 روی جیمیل و یا لینکدین من مکاتبه کنید. مبین رنجبر مبین رنجبر Tue, 19 Aug 2025 10:07:14 +0330 https://virgool.io/bigdataengineer/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%B9%D9%85%D9%84%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D9%87%D8%A7%DB%8C-%DA%A9%D9%84%D8%A7%D9%86-%D8%AF%D8%A7%D8%AF%D9%87-%D9%85%D9%82%D8%AF%D9%85%D9%87-%D9%88-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-ian9iucx64eo به روزرسانی: بخش دوم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.در انتهای سال 1398 درگیر پروژه ای در ایران بودم که نیاز به امن‌سازی زیرساخت های کلان داده مبتنی بر هدوپ و اسپارک داشتند. به همین جهت در کنار اقدامات عملی انجام گرفته، مستندی تقریبا 100 صفحه‌ای از نیازمندی ها و شرح مراحل تولید کردم و در اختیار تیم مربوطه قرار دادم. پس از گذشت سال‌ها درخواست‌ها و سوالات زیادی در این باره از من شد که منابع موردنیاز را در اختیارشان قرار دهم. خب بخشی از این منابع برای کاربر فارسی زبان نامفهوم بود و بخشی دیگر نیز با توجه به تخصصی بودن ابزارها، کمبود منابع حتی انگلیسی حس می‌شد.در ابتدا فایل PDF این کتابچه را در لینکدین خودم برای فروش قراردادم ولی پس از مدتی تصمیم گرفتم این کتابچه را در بخش های مختلف به صورت رایگان منتشر کنم تا همه استفاده کنند و باقیات الصالحات بشود. :)بسته به اینکه چقدر از این کار استقبال خواهد شد، موارد مشابه دیگری از این دست اقدامات هم کم نبوده در مسیر شغلی مهندسی کلان داده من (در قالب موسس، عضو هیئت مدیره و مشاور شرکت هایی که محصول و تفکری مرتبط با داده ها و به طور اخص کلان داده داشته اند) پست های بیشتری در این مورد خواهم نوشت.به دلیل طولانی بودن برخی از تنظیمات، فایل های موردنیاز در مخزن گیت هاب در این لینک قابل دسترس می باشند.نکته مهم اول: این مستند خالی از اشکال و اشتباه نیست.نکته مهم دوم: ابزارهای مورد بحث قرارگرفته در این نوشتارها به این دلیل انتخاب شده اند که در اکثر معماری های معمول و استاندارد زیرساخت های کلان داده در ایران و جهان وجود دارند.این بخش از این نوشتار بیشتر مربوط به مقدمات و توضیحات اولیه می باشد و بخش های دیگر را به مرور منتشر خواهم کرد.به دلیل مرتبط بودن این پروژه با صنعت مالی و بانکی، تمرکز مسائل برروی این صنعت می باشد.عناوین کلی و مباحثی که بحث خواهم کرد به قرار زیر خواهد بود:1. مقدمه2. بررسی ماهیت امنیت در صنعت بانکداری3. امنیت زیرساخت های کلان داده4. معرفی فریم ورک مدیریت و پردازش کلان داده هدوپ (Hadoop)5. امنیت در هدوپ6. نصب و راه اندازی Kerberos7. شروع کار با Kerberos8. پیکربندی هدوپ و فعال سازی Kerberos در آن9. پیکربندی هدوپ با قابلیت دسترس‌پذیری یا High Availability10. معرفی ابزار Apache Ranger11. نصب و پیکربندی Ranger Admin12. نصب و پیکربندی Ranger UserSync13. نصب و راه اندازی افزونه هدوپ(سرویس HDFS و YARN) در Ranger Admin14. اتصال سرویس های هدوپ به Ranger Admin15. تعریف سیاست های دسترسی در Ranger Admin16. نصب و راه اندازی افزونه Spark SQL17. نصب و راه اندازی Livy و اجرای مثال مرتبطمقدمهدر سال های اخیر سیستم بانکی کشور دستخوش تغییراتی بوده است که بخش بزرگی از این تغییرات را رشد داده ها رغم زده اند. داده نوعی موجودیت است که با کالبد شکافی آن می توان به اطلاعات رسید و اطلاعت، سرمایه ای برای هر سازمان است تا بتواند به سودآوری هر چه بیشتر آن کمک کند. این روزها مفهوم کلان داده یا داده های بزرگ در دنیا بسیار قابل توجه شده است و سازمان ها و شرکت های بزرگ در تلاش می باشند تا خود را با این مفهوم چه از لحاظ زیر ساخت سخت افزاری و چه از لحاظ نرم افزاری و همچنین تغییر در نگرش توسعه و نگهداری نرم افزار های موجودشان همگام سازند. در کنار تمامی پتانسیل های مفید و قابل توجه زیرساخت کلان داده، نگرانی مهمی که نباید از آن غافل شد بحث امنیت است.به دلیل جدید بودن موضوع و همچنین نبود کافی نیروی متخصص در این حوزه می تواند سازمانی که از این ابزارها استفاده می کند را با ریسکی بزرگ مواجه کند. به علت ساده سازی فرآیند راه اندازی و اجرای ابزارها، سازندگان آنها در تلاشند جنبه های مختلف مانند امنیت را نادیده بگیرند تا بتوانند به صورت سریع و آسان ماهیت خود را به کاربران خود نشان دهند. این موضوع را نمی توان نقص در ابزار دانست. پس می توان اینگونه توصیف کرد که ابزارهای موجود، هیچ ساز و کار امنیتی در استفاده از آنها به صورت پیش فرض فعال نمی باشد.در این سند قصد داریم به بررسی و ارائه راهکارهای عملی ایجاد امنیت در زیرساخت کلان داده بپردازیم.بررسی ماهیت امنیت در صنعت بانکداریامن بودن یا امنیت داشتن یک گزاره نسبی است. به این معنی که نمی توان همواره امنیت کامل و صددرصدی را ایجاد نمود. اما می توان بالاترین سطح را برای آن برشمرد. مدیریت امنیت تمام فرایندها را از پایین‌ترین سطح که فناوری است تا بالاترین سطح که تدوین راهبردهای کلان امنیتی است دربر می‌گیرد. اصولا دست‌یابی به امنیت بدون برنامه‌ریزی و داشتن راهبردهای مشخص امکان‌پذیر نیست، این در حالی است که معمولا وقتی صحبت از امنیت می‌شود در بیشتر موارد فقط سطح پایین (فناوری) مد نظر قرار می‌گیرد. از مهمترین راهبردهایی که انتظار می‌رود مدیریت امنیت ایجاد کند مدیریت مخاطرات(ریسک) است. در همین رابطه یک اشتباه رایجی وجود دارد. معمولا سازمان‌ها تمایل دارند بگویند ما امن هستیم. این در حالی است که وجود امنیت در دنیا مفهوم خاصی ندارد، آنچه می‌توان گفت این است که سازمان مخاطرات و امنیت خود را مدیریت می‌کند. طبق یک پژوهش که در سال 2010 انجام شده است، در صدر عواملی که بانک‌ها مشتاق به سرمایه‌گذاری در امر امنیت هستند، اعتماد مشتریان به چشم می‌خورد. بحث اعتماد شاید در هیچ صنعت دیگری اینقدر اهمیت نداشته باشد. ممکن است هک یک کارت ضرر مالی چندانی به بار نیاورد اما جنبه اعتماد عمومی آن خیلی ارزش دارد. سایر عوامل با اهمیت در این زمینه به ترتیب مباحث مالی، الزامات قانونی و تقاضای مشتریان است. در دنیای مدیریت سنتی داده ها مفهومی به نام Three As وجود دارد که در شکل 1 نمایش داده شده است.شکل 1در شکل 1 سه مفهوم اصلی امنیت معرفی شده است که در زیر آنها را به اختصار شرح می دهیم:1. مفهوم Authentication یا احراز هویت: فرآیندی است که به نوع اعتبارسنجی و تشخیص هویت کاربر در یک شبکه یا نرم افزار می پردازد. معمول ترین روش آن در این مفهوم همان اعتبارسنجی نام کاربری و رمز عبور است.2. مفهوم Authorization یا اعطای مجوز: فرآیندی است که مشخص می کند کاربر 'X' اجازه دارد به کدام داده، کدام نوع داده و کدام سرویس دسترسی یابد.توجه داشته باشید که دو مفهوم شرح داده شده در بالا یکسان نیستند و وجه افتراق مهمی دارند. احراز هویت در واقع اثبات هویت واقعی کاربر است. به این معنی که آیا کاربری که درخواست دسترسی خاصی را دارد، خود واقعی است یا جعل هویت کرده است. اما در اعطای مجوز بررسی می شود آیا کاربری که هویت خود را احراز کرده است به داده، نرم افزار یا سرویس موردنظر اجازه دسترسی دارد یا خیر.3. مفهوم Auditing یا بازرسی: فرآیندی است که به پایش و نظارت کاربرانی می پردازد که به آنها اجازه دسترسی داده شده است. در واقع سوالی که در این فرآیند مطرح می شود این است که چه داده هایی توسط کدام کاربر دسترسی تغییر و ویرایش یافته است.امنیت زیرساخت های کلان دادههمانطور که می دانید امنیت به تمامی لایه های سخت افزاری و نرم افزاری بسط داده می شود. منظور ما در این سند امنیت در سطح داده های موجود برروی نرم افزار و یا سرویس مورد بحث می باشد و مباحث مربوط به امنیت در لایه سخت افزار، برقراری امنیت از طریق دیواره های آتش و... خارج از حوصله این سند می باشد و به صورت پیش فرض لایه های زیرین زیرساخت کلان داده نظیر شبکه و سخت افزار را امن فرض می کنیم. مشابه سیستم های عامل موجود برروی کامپیوترهای امروزی، در لایه نرم افزاری زیرساخت کلان داده به ویژگی اصلی یک سیستم عامل یعنی دسترسی به فایل ها و زمان بندی برنامه ها پرداخته می شود. خصیصه اصلی یک زیرساخت کلان داده، توزیع شدگی آن است که این خصیصه می باشد در سیستم فایل و زمان بندی برنامه ها نیز صدق کند. در این سند نگارنده فرض می کند شما به مفاهیم شبکه ها و سیستم های توزیع شده و مفاهیم کاربری سیستم عامل گنولینوکس آشنایی کافی را دارید.بنابراین بحث امنیت در زیرساخت کلان داده را مترادف امنیت در فریم ورک مدیریت و پردازش کلان داده هدوپ قرار می دهیم. به این دلیل که فریم ورک هدوپ، در واقع سیستم عامل زیرساخت کلان داده ما می باشد که به پیاده سازی و اجرای توزیع شده امکان مدیریت فایل ها و زمان بندی برنامه ها می پردازد. فریم ورک هدوپ را به صورت اختصار شرح خواهیم داد.معرفی فریم ورک مدیریت و پردازش کلان داده هدوپ (Hadoop)به طور خلاصه ، هدوپ یک فریم ورک یا مجموعه ای از نرم افزارها و کتابخانه هایی است که ساز و کار پردازش حجم عظیمی از داده های توزیع شده را فراهم میکند. در واقع هدوپ را می توان به یک سیستم عامل تشبیه کرد که طراحی شده تا بتواند حجم زیادی از داده ها را بر روی ماشین های مختلف پردازش و مدیریت کند. هدوپ از دو جزء اصلی یعنی سیستم فایل توزیع شده هدوپ یا HDFS و زمان بند توزیع شده منابع یا YARN تشکیل می شود. سیستم فایل توزیع شده هدوپ نیازمند کامپیوترهای گران قیمت نیست و می توان با استفاده از کامپیوترهای ارزان و معمول مورد استفاده قرار گیرد. این سیستم فایل از کارایی بالایی برخوردار است. برای بالابردن کارایی دسترسی این سیستم فایل، فایل ها را در نزدیک ترین شبکه به سرویس گیرنده در شبکه ای مشابه تکثیر می کند. اگرچه، اشکال کل شبکه باعث از بین رفتن تمامی فایل هایی می شود که در این شبکه ذخیره شده اند.این سیستم فایل توزیع شده تحت هدوپ کار می کند و یک چارچوبی برای تحلیل و تغییرشکل مجموعه داده های بسیار بزرگ با استفاده از Map/Reduce می باشد. یکی از مهم ترین ویژگی های هدوپ،پارتیشن بندی داده ها و محاسبات میان هزاران میزبان و اجرای برنامه های محاسباتی موازی بر روی داده هایشان است. یک خوشه هدوپ می تواند از نظر ظرفیت محاسباتی،ظرفیت ذخیره سازی و پهنای باند ورودی و خروجی از طریق اضافه کردن سرورهای معمولی توسعه یابد. کلاسترهای هدوپ در شرکت یاهو به 25000 سرور می رسند و 25 پتابایت از داده های برنامه های مختلف را ذخیره می کنند و بزرگ ترین کلاستر یاهو حاوی 3500 سرور است. تا به حال 100 سازمان جهانی اعلام کرده اند که از هدوپ استفاده می کنند.HDFS جزئی از سیستم فایل هدوپ می باشد و فراداده و داده های برنامه ها را به صورت جداگانه ذخیره می کند. همانند سیستم فایل های دیگر مثل PVFS ، Lustre و GFS ، HDFS فراداده را بر روی یک سرور اختصاصی به نام NameNode ذخیره می کند. داده های برنامه ها نیز بر روی سرور های دیگر به نام DataNodes ذخیره می شوند. تمامی این سروری با هم از طریق پروتکل های مبتنی بر TCP با هم در ارتباط هستند. زمان بند توزیع شده منابع YARN که سرنام Yet Another Resource Negotiator است در واقع نسل بعدی MapReduce است که به نام MRv2 هم شناخته می شود. MapReduce در هدوپ نسخه ۰.۲۳ تغییرات کلی یافت و آن‌چه که اکنون در دسترس ماست MRv2 یا MapReduce 2.0 یا YARN نامیده می‌شود که در آن بین مدیریت منابع و مولفه‌های پردازشی، جداسازی صورت گرفته است. در حقیقت مفهوم YARN در اثر نیاز به طیف وسیع‌تری از الگوهای تعاملی برای ذخیره داده‌ها، در HDFS مبتنی بر MapReduce متولد شده است. معماری مبتنی بر YARN از هدوپ نسخه ۲.۰ یک بستر پردازشی عمومی‌تر ساخته است که محدود به MapReduce نیست.امنیت در هدوپهدوپ به صورت پیش فرض بدون هیچ ساز و کار امنیتی و بدون اعتبارسنجی اجرا می شود و هدوپ فرض را بر این قرار می دهد که "همه چی آرومه". در واقعیت هیچ وقت اینطور نیست و بلاخره هدوپ در محیط های واقعی مورد استفاده قرار می گیرد و همیشه در محیط آزمایشگاهی امن نخواهیم ماند. در واقع کاربری که می خواهد با هدوپ کار کند کافی است نام کاربری خودش را به هدوپ معرفی کند و هدوپ هم (به صورت پیش فرض) فکر میکند کاربر موردنظر درست می گوید و بدون هیج اعتبارسنجی نه تنها خودش اجازه فعالیت به آن کاربر می دهد، بلکه به تمامی ماشین ها در شبکه اعلام می کند که این کاربر اجازه فعالیت دارد. در اینجا یک مشکل داریم. اگر کاربر موردنظر خودش را به جای کاربر دیگری معرفی کند چه اتفاقی می افتد؟ مسلما هدوپ به او اجازه فعالیت می دهد چرا که خودش را کاربر x معرفی کرده است. به عنوان مثال فرض کنید در یک میهمانی اگر کسی به شما بگوید "من علی هستم" شما بدون هیچ سوالی باور می کنید که او علی است چرا که خودش گفته است. مشکل اینجاست که نه تنها هدوپ باور میکند او علی است بلکه به تمامی افراد دیگر هم می گوید "او علی است".تا اینجا مشکل را درک کردیم. حالا نوبت به معرفی راهکار می رسد.مکانیزم های اصلی امنیت در هدوپ عبارتند از:1. لیست کنترل دسترسی استاندارد POSIX یا POSIX Access Control List(ACL)2. اعطای مجوز سطح سرویس یا Service Level Authorization(SLA)3. مجوز امنیتی Kerberos4. کلاس سفارشی یا Customتوجه داشته باشید که هرکدام از مکانیزم های بالا در سطح های متفاوتی از احراز هویت و اعتبارسنجی فعالیت می کنند. به همین دلیل برای پیاده سازی و استفاده از هردو سطح، می توان آنها را به صورت ترکیبی با یکدیگر مورد استفاده قرار داد. در زیر هرکدام از این مکانیزم ها را شرح می دهیم:مکانیزم لیست کنترل دسترسی یا Access Control List (ACL)به صورت پیش فرض در هدوپ این امکان غیرفعال می باشد و برای استفاده از این امکان می باشد تنظیمات مربوطه را فعال نمایید. به این معنی که هر کاربری اجازه انجام هرکاری را دارد. اما اگر این امکان را فعال کنید، در هنگام نصب و راه اندازی هدوپ، کاربر سیستمی که هدوپ را اجرا می کند به صورت پیش فرض به عنوان کاربر مدیر تعیین می شود و اجازه انجام هر عملیاتی را دارا می باشد.به طور مثال هدوپ را در پوشه Home کاربر hduser قرار داده اید و آنرا اجرا می کنید. در هنگام کار با سیستم فایل توزیع شده هدوپ، سطح دسترسی و مالک فایل ها و پوشه ها به صورت پیش فرض hduser انتخاب می شود و اگر بخواهید با کاربر سیستمی دیگری با این سیستم فایل کار کنید اجازه نخواهید داشت. البته اگر کاربری که دسترسی لازم را دارد به شما یک پوشه با سطح دسترسی مشخص تخصیص دهد شما می می توانید بدون مشکل فایل ها و پوشه های خود را در آن مسیر مخصوص قرار دهید. استاندارد سطح دسترسی در اینجا همان POSIX است. در سیستم عامل لینوکس سه سطح دسترسی برای فایل و فولدرها وجود دارد:اجازه خواندن فایل را میدهد :readاجازه نوشتن و ویرایش در فایل را میدهد :writeاجازه اجرای فایل را میدهد :executeاین سه سطح دسترسی به صورت r - w - x مشخص میشوند که برای هر کدام از آنها یک عدد در نظر گرفته شده است:r → 4w → 2x → 1 در لینوکس سه کلاس برای کاربران وجود دارد: owner - group - other که میتوان برای هر کدام سطح دسترسی تعیین نمود.مثال:rw-rw-r → 644سطح دسترسی در مثال بالا 644 است که در آن rw برابر با 6 در نظر گرفته میشود.برای تغییر سطح دسترسی ها در لینوکس از فرمان chmod استفاده میشود. نحوه استفاده به صورت زیر است: chmod [permissions] [path]مثال:chmod 755 testدر این مثال دسترسی به فایل test برای owner برابر با 7 یا rwx ، برای group برابر با 5 یا rx و برای other برابر با 5 یا rx خواهد بود.755 → rwx-rx-rx به طور کلی در لینوکس ۲ کاربر داریم که یکی root یا کاربر ریشه است و تمامی تنظیمات و تغییرات را میتواند انجام دهد و مشابه administrator در هاست ویندوز است و یک کاربر دیگر هم وجود دارد که خود شما هستید و یا شخصی که از سیستم استفاده میکند.به طور مثال میخواهیم به کاربر hduser دسترسی خواندن و نوشتن به فایلی به نام myfile در مسیر /user/hdfs برروی فایل سیستم توزیع شده هدوپ را بدهیم. به صورت زیر عمل می کنیم:ابتدا در فایل hdfs-site.xml تنظیمات زیر را اعمال می کنیم:<property><name>dfs.namenode.acls.enabled</name><value>true</value></property>حالا با دستور زیر دسترسی موردنظر را اعمال می کنیم:hdfs dfs -setfacl -m user:hduser:rw- /user/hdfs/myfileنکته قابل توجه در این مکانیزم این است که ACL در واقع فقط وظیفه Authorization یا اعطای مجوز را بر عهده دارد و عملیات احراز هویت یا Authentication بر عهده سیستم عامل میزبان است. شاید این یک نقص باشد ولی با اینکار مسئولیت احراز هویت را از خود سلب می کند تا محدودیتی در انتخاب شیوه احراز هویت برای کاربر ایجاد نکند. با این حال شاید بهتر باشد ما از مکانیزمی استفاده کنیم که هردو وظیفه اعطای مجوز و احراز هویت را انجام دهد.مکانیزم اعطای مجوز سطح سرویس یا Service Level Authorization (SLA)این مکانیزم در واقع راهکار ابتدایی هدوپ برای اعطای مجوز می باشد که از لیست کنترل دسترسی یا ACL است با این تفاوت که از لیست از پیش تعریف شده کاربران و گروه کاربری استفاده می کند تا دسترسی یا عدم دسترسی به سرویس خاصی را مدیریت کند.به طور مثال می خواهیم به کاربر hduser اجازه اجرای برنامه را برروی YARN بدهیم. در مسیر تنظیمات هدوپ که به صورت پیش فرض مسیر $HADOOP_HOME/etc/Hadoop است فایلی به نام Hadoop-policy.xml وجود دارد که وظیفه نگهداری تنظیمات اعطای مجوز سطح سرویس را دارا می باشد. برای فعال سازی و اعطای مجوز به کاربر hduser در ابتدا می بایست تنظیمات زیر را در فایل تنظیمات core-site.xml اعمال کنیم:<property><name>hadoop.security.authentication</name><value>kerberos</value></property><property><name>hadoop.security.authorization</name><value>true</value></property>و سپس در فایل تنظیمات Hadoop-policy.xml مقدار زیر را اضافه می کنیم:<property><name>security.job.client.protocol.acl</name><value>hduser</value></property>مکانیزم امنیتی Kerberosدانشمندان علوم کامپیوتر دانشگاه MIT، اولین پژوهشگرانی بودند که از واژه Kerberos (یکی از قهرمان اساطیر یونانی) برای نام‌گذاری یک پروتکل احراز هویتی استفاده کردند که درون شبکه‌های کامپیوتری استفاده می‌شود. کربروس (Kerberos) یک پروتکل تحت شبکه است که در سطحی گسترده برای حل مشکل احراز هویت استفاده می‌شود. کربروس از رمزنگاری کلید متقارن و یک مرکز توزیع کلید KDC سرنام Key Distribution Center استفاده می‌کند و برای تایید هویت کاربر به مجوز ثالث مورد اعتماد نیاز دارد. کربروس به 3 عنصر مجزا برای احراز هویت نیاز دارد و از یک سیستم رهگیری و نظارتی قدرتمند برای امن‌تر نگه داشتن محاسبات استفاده می‌کند. احراز هویت کربروس در حال حاضر فناوری احراز هویت پیش‌فرض ویندوز مایکروسافت است، اما پیاده‌سازی کربروس در یونیکس، لینوکس Apple OS و FreeBSD امکان‌پذیر است. مایکروسافت نسخه کربروس خود را همراه با ویندوز 2000 معرفی کرد. همچنین این فناوری به یک استاندارد برای وبسایت‌ها و احراز هویت شناسایی یگانه (Single Sign-On) در پلتفرم‌های مختلف تبدیل شده است. لازم به توضیح است که کنسرسیوم کربروس این فناوری را به عنوان یک پروژه منبع‌باز نگه‌داری می‌کند. کربروس به نسبت فناوری‌های احراز هویت قبل از خود پیشرفت چشم‌گيری داشته است. رمزنگاری قدرتمند و توکن احراز هویت ثالث باعث می‌شوند تا نفوذ به شبکه توسط مجرمان سایبری با دشواری زیادی همراه باشد. این فناوری همانند سایر نمونه‌های مشابه در بخش‌هایی آسیب‌پذیر است که اگر درباره این آسیب‌پذیرها اطلاع کافی داشته باشید، دفاع در برابر هکرها امکان‌پذیر می‌شود. کربروس اینترنت را به محیطی امن‌تر تبدیل کرد و این امکان را برای کاربران فراهم کرد تا فارغ از نگران‌های امنیتی و بدون نگرانی از بابت مشکلات امنیتی در دفتر کار خود با اینترنت کار کنند.قبل از کربروس مایکروسافت از یک فناوری احراز هویت به‌نام NT Lan Manager(NTLM) استفاده می‌کرد که یک پروتکل احراز هویت چالش-پاسخ بود. کامپیوتر یا کنترل‌کننده دامنه گذرواژه‌ها را بررسی و هش گذرواژه را برای استفاده مداوم ذخیره می‌کرد. بزرگ‌ترین تفاوت این دو سیستم در احراز هویت ثالث و توانایی رمزنگاری قدرتمندتر کربروس است. کربروس در مقایسه با NTLM از یک لایه امنیتی اضافی در فرآیند احراز هویت استفاده می‌کند. این روزها سیستم‌های مبتنی بر NTLM را می‌توان در عرض چند ساعت هک کرد. به بیان ساده NTLM یک فناوری قدیمی‌ و به تعبیری منسوخ شده است که نباید برای محافظت از داده‌های حساس از آن استفاده کرد.هر هویت(کاربر یا سرویس) در Kerberos به عنوان یک Principal شناخته می شود. هویت های کاربری را UPN یا User Principal Names و هویت های مبتنی بر سرویس را SPN یا Service Principal Names می نامند. UPN ها در واقع همان کاربر عادی در دنیای واقعی است ولی SPN ها سرویس هایی را معرفی می کند که کاربر میخواهد به آن دسترسی یابد.در Kerberos می توان محدوده قلمرو مشخص کرد که به آن realm گفته می شود. به طور مثال اگر یک شرکت بخواهد از سیستم اعتبارسنجی Kerberos استفاده کند می تواند برای هر بخش شرکت یک قلمرو ایجاد کند مثلا قلمرو تیم بازاریابی و تیم برنامه نویسی. ارتباط بین این قلمرو ها می تواند یک طرفه و یا دوطرفه باشد به اینصورت که تیم بازاریابی دسترسی کاربری به قلمرو برنامه نویسان ندارد ولی قلمرو برنامه نویسان دسترسی به قلمرو تیم بازاریابی دارد. این یک ارتباط یک طرفه است. تمامی این اطلاعات در KDC یا Key Distribution Center ذخیره می شود. هر KDC از سه بخش زیر تشکیل می شود:Kerberos DatabaseAuthentication Service(AS)Ticket-granting Service(TGS)در واقع پایگاه داده Kerberos اطلاعات مربوط به هویت ها و قلمروها را نگه داری می کند.به طور مثال هویت کاربری ali در قلمرو EXAMPLE.COM به صورت زیر معرفی می شود(دقت کنید که هویت ها می بایست با حروف کوچک و قلمروها با حروف بزرگ نوشته شوند):ali@EXAMPLE.COMهویت مبتنی بر سرویس یا SPN نیز به صورت زیر تعریف می شود:hdfs/node1.example.com@EXAMPLE.COM در اعلان بالا hdfs نام سرویسی بر روی میزبان node1.example.om می باشد که در قلمرو EXAMPLE.COM قرار دارد.اجزای دیگر KDC یعنی AS و TGS وظیفه اعطای مجوز را در لایه امنیتی Kerberos بر عهده دارند.در شکل 2 روند اعطای مجوز به کاربر را می توانید مشاهده کنید:شکل 2ادامه دارد ...به روزرسانی: بخش دوم این مستند منتشر شد. پس از مطالعه این بخش، به سراغ قسمت بعدی در این لینک بروید.با من در بخش های دیگر این مستند همراه باشید و در صورت وجود ابهام و سوال و ارتباط با من می توانید با ایمیل من mobinranjbar1 روی جیمیل و یا لینکدین من مکاتبه کنید. مبین رنجبر مبین رنجبر Sat, 16 Aug 2025 12:51:22 +0330