انتخاب زبان

زیرساخت محاسباتی و ذخیره‌سازی فدرال ناهمگن برای PUNCH4NFDI

تحلیل مفاهیم Compute4PUNCH و Storage4PUNCH برای فدراسیون‌سازی منابع متنوع HPC، HTC و ذخیره‌سازی در مؤسسات تحقیقاتی آلمان.
computingpowertoken.net | PDF Size: 0.5 MB
امتیاز: 4.5/5
امتیاز شما
شما قبلاً به این سند امتیاز داده اید
جلد سند PDF - زیرساخت محاسباتی و ذخیره‌سازی فدرال ناهمگن برای PUNCH4NFDI

1. مقدمه

کنسرسیوم PUNCH4NFDI (ذرات، کیهان، هسته‌ها و هادرون‌ها برای زیرساخت ملی داده‌های پژوهشی)، که توسط بنیاد پژوهشی آلمان (DFG) تأمین مالی می‌شود، نماینده حدود ۹۰۰۰ دانشمند از جوامع فیزیک ذرات، اخترفیزیک، اخترذرات، هادرون و فیزیک هسته‌ای است. این کنسرسیوم که در چارچوب گسترده‌تر ابتکار NFDI جای گرفته، هدف اصلی آن ایجاد یک پلتفرم علمی داده‌ای فدرال و FAIR (قابل جستجو، قابل دسترسی، قابل تعامل و قابل استفاده مجدد) است. این پلتفرم در پی فراهم‌آوردن دسترسی یکپارچه به منابع محاسباتی و ذخیره‌سازی متنوع مؤسسات عضو است تا چالش‌های مشترک ناشی از رشد نمایی حجم داده‌ها و الگوریتم‌های تحلیل محاسباتی فشرده را برطرف کند. این سند بر مفاهیم معماری—Compute4PUNCH و Storage4PUNCH—تمرکز دارد که برای فدراسیون‌سازی زیرساخت پژوهشی ناهمگن آلمان طراحی شده‌اند.

2. زیرساخت محاسباتی فدرال ناهمگن – Compute4PUNCH

Compute4PUNCH چالش استفاده مؤثر از طیف گسترده‌ای از منابع اهدایی عینی، شامل سیستم‌های محاسباتی با توان عملیاتی بالا (HTC)، محاسبات با کارایی بالا (HPC) و ابری را که در سراسر آلمان توزیع شده‌اند، مورد توجه قرار می‌دهد. این منابع از نظر معماری، سیستم‌های عامل، پشته‌های نرم‌افزاری و سیاست‌های دسترسی متفاوت هستند. اصل طراحی هسته، ایجاد یک سیستم روکشی یکپارچه با حداقل مداخله در ارائه‌دهندگان منابع عملیاتی موجود است.

2.1. معماری هسته و یکپارچه‌سازی

فدراسیون حول HTCondor به عنوان روکش سیستم دسته‌ای مرکزی ساخته شده است. منابع ناهمگن به صورت پویا با استفاده از فراسنجش‌گر منابع COBalD/TARDIS یکپارچه می‌شوند. COBalD/TARDIS به عنوان یک کارگزار هوشمند عمل می‌کند که وظایف را بر اساس در دسترس بودن منابع، نیازمندی‌های کار و سیاست‌ها، به بک‌اندهای مناسب (مانند خوشه‌های Slurm، Kubernetes) هدایت می‌کند. این امر یک مخزن منطقی واحد از سیستم‌های فیزیکی پراکنده ایجاد می‌کند.

2.2. دسترسی کاربر و محیط نرم‌افزاری

نقاط ورود کاربر از طریق گره‌های ورود سنتی و یک سرویس JupyterHub فراهم می‌شود. یک زیرساخت احراز هویت و مجوزدهی (AAI) مبتنی بر توکن، دسترسی را استاندارد می‌کند. پیچیدگی محیط نرم‌افزاری از طریق فناوری‌های کانتینر (مانند Docker، Singularity/Apptainer) و سیستم فایل ماشین مجازی سرن (CVMFS) مدیریت می‌شود که توزیع‌های نرم‌افزاری مقیاس‌پذیر و فقط خواندنی را به گره‌های محاسباتی در سطح جهانی ارائه می‌دهد.

3. زیرساخت ذخیره‌سازی فدرال – Storage4PUNCH

Storage4PUNCH هدف فدراسیون‌سازی سیستم‌های ذخیره‌سازی ارائه شده توسط جامعه را دنبال می‌کند که عمدتاً بر پایه فناوری‌های dCache و XRootD هستند و در فیزیک انرژی بالا (HEP) به خوبی جا افتاده‌اند. این فدراسیون از فضای‌نام‌ها و پروتکل‌های مشترک (مانند xrootd، WebDAV) برای ارائه یک لایه دسترسی یکپارچه به داده استفاده می‌کند. این مفهوم همچنین یکپارچه‌سازی راه‌حل‌های کش و سرویس‌های مدیریت فراداده را برای بهبود محل‌یابی داده و قابلیت کشف در سراسر فدراسیون ارزیابی می‌کند.

4. پیاده‌سازی فنی و مؤلفه‌ها

4.1. احراز هویت و مجوزدهی (AAI)

یک AAI مبتنی بر توکن (احتمالاً با بهره‌گیری از استانداردهای OAuth 2.0/OpenID Connect، مشابه WLCG IAM یا INDIGO IAM) تجربه ورود یکپارچه ارائه می‌دهد. این سیستم، هویت‌های جامعه را به مجوزهای منابع محلی نگاشت می‌کند و سیستم‌های احراز هویت محلی ناهمگن (مانند Kerberos، کلیدهای SSH) را انتزاعی می‌کند.

4.2. فراسنجش منابع: COBalD/TARDIS

COBalD (هماهنگ‌کننده) و TARDIS (سیستم یکپارچه‌سازی پویای منابع تطبیقی شفاف) به صورت هماهنگ کار می‌کنند. COBalD تصمیمات سطح بالای زمان‌بندی را می‌گیرد، در حالی که TARDIS چرخه عمر «خلبان‌ها» یا «وظایف نگهدارنده مکان» را در منابع هدف مدیریت می‌کند. این جداسازی امکان اعمال سیاست‌های انعطاف‌پذیر (مانند هزینه، انصاف، اولویت) و سازگاری پویا با حالت‌های نوسانی منابع را فراهم می‌کند. زمان‌بندی را می‌توان به عنوان یک مسئله بهینه‌سازی مدل کرد که یک تابع هزینه $C_{total} = \sum_{i}(w_i \cdot T_i) + \lambda \cdot R$ را کمینه می‌کند، که در آن $T_i$ زمان چرخش برای کار $i$، $w_i$ وزن اولویت آن، $R$ نشان‌دهنده هزینه استفاده از منابع و $\lambda$ یک پارامتر تعادل است.

4.3. لایه داده و نرم‌افزار

CVMFS برای توزیع نرم‌افزار حیاتی است. این سیستم از یک مدل ذخیره‌سازی آدرس‌پذیر محتوا و کش‌گذاری تهاجمی (با سرورهای Stratum 0/1 و کش‌های محلی Squid) برای ارائه مخازن نرم‌افزاری به‌طور کارآمد استفاده می‌کند. احتمالاً فدراسیون از سلسله‌مراتبی از لایه‌های CVMFS استفاده می‌کند، با یک لایه ۰ مخزن مرکزی PUNCH و آینه‌های لایه ۱ مؤسسه‌ای. دسترسی به داده از یک مدل فدرال مشابه پیروی می‌کند، که در آن عناصر ذخیره‌سازی (SEها) نقاط پایانی خود را به یک دایرکتوری جهانی (مانند Rucio یا یک سرویس REST ساده) اعلام می‌کنند و به کلاینت‌ها اجازه می‌دهند مکان داده‌ها را به صورت شفاف حل کنند.

5. وضعیت نمونه اولیه و تجربیات اولیه

این سند نشان می‌دهد که نمونه‌های اولیه هر دو Compute4PUNCH و Storage4PUNCH عملیاتی هستند. کاربردهای علمی اولیه اجرا شده‌اند که بازخورد ارزشمندی در مورد عملکرد، قابلیت استفاده و نقاط درد یکپارچه‌سازی ارائه داده‌اند. اگرچه اعداد معیار خاصی در این گزیده ارائه نشده است، اجرای موفقیت‌آمیز، عملکرد پایه سیستم دسته‌ای روکشی، یکپارچه‌سازی AAI و تحویل نرم‌افزار از طریق CVMFS را تأیید می‌کند. این تجربیات در حال هدایت اصلاحات در پیکربندی سیاست، مدیریت خطا و مستندات کاربر هستند.

6. بینش‌های کلیدی و تحلیل راهبردی

بینش هسته‌ای: PUNCH4NFDI در حال ساخت یک ابررایانه جدید نیست؛ بلکه در حال مهندسی یک «پارچه فدراسیونی» است که به صورت عمل‌گرایانه منابع موجود و تکه‌تکه شده را به هم می‌دوزد. این یک تغییر راهبردی از زیرساخت یکپارچه به تجمیع منابع چابک و تعریف‌شده توسط نرم‌افزار است که روندهای موجود در ابر تجاری را بازتاب می‌دهد اما برای محدودیت‌ها و فرهنگ آکادمی با بودجه عمومی سفارشی شده است.

جریان منطقی: معماری از یک منطق واضح و وابسته به وابستگی پیروی می‌کند: ۱) یکپارچه‌سازی هویت (AAI) برای حل مسئله «چه کسی»، ۲) انتزاع منابع (COBalD/TARDIS + HTCondor) برای حل مسئله «کجا»، و ۳) جداسازی محیط (کانتینرها + CVMFS) برای حل مسئله «با چه چیزی». این انتزاع لایه‌ای، مهندسی سیستم‌های کلاسیک است که موفقیت شبکه محاسباتی جهانی LHC (WLCG) را به یاد می‌آورد، اما بر مجموعه منابع متنوع‌تری اعمال شده است.

نقاط قوت و ضعف: نقطه قوت اصلی آن مدل پذیرش غیرمخرب است. با استفاده از فناوری‌های روکشی و احترام به استقلال سایت، مانع برای ارائه‌دهندگان منابع کاهش می‌یابد—عامل موفقیت حیاتی برای کنسرسیوم‌ها. با این حال، این نیز نقطه آسیب‌پذیر آن است. سربار عملکردی فراسنجش و پیچیدگی ذاتی اشکال‌زدایی در سیستم‌های ناهمگن و مدیریت‌شده مستقل می‌تواند قابل توجه باشد. دستور «حداقل مداخله» ممکن است توانایی پیاده‌سازی ویژگی‌های پیشرفته مانند اتصال عمیق ذخیره‌سازی-محاسبه یا تأمین شبکه پویا را محدود کند و به طور بالقوه دستاوردهای کارایی را محدود کند. در مقایسه با یک سیستم متمرکز و هدف‌ساز مانند Borg گوگل یا خوشه Kubernetes، فدراسیون همیشه تأخیر بیشتر و قابلیت پیش‌بینی پایین‌تری در استفاده خواهد داشت.

بینش‌های عملی: برای سایر کنسرسیوم‌هایی که این مسیر را در نظر می‌گیرند: ۱) از روز اول به شدت در نظارت و مشاهده‌پذیری سرمایه‌گذاری کنید. ابزارهایی مانند Grafana/Prometheus برای زیرساخت و APM (نظارت بر عملکرد برنامه) برای کارهای کاربر برای مدیریت پیچیدگی غیرقابل مذاکره هستند. ۲) روی مجموعه محدودی از تصاویر پایه کانتینر استانداردسازی کنید تا بار نگهداری CVMFS کاهش یابد. ۳) یک مدل پشتیبانی واضح و لایه‌بندی شده توسعه دهید که مسائل سطح فدراسیون را از مشکلات سایت محلی متمایز کند. آزمون واقعی امکان‌پذیری فنی نخواهد بود—جامعه HEP این را ثابت کرده است—بلکه پایداری عملیاتی و رضایت کاربر در مقیاس است.

7. بررسی عمیق فنی

مدل ریاضی برای زمان‌بندی منابع: سیستم COBalD/TARDIS را می‌توان به عنوان حل یک مسئله بهینه‌سازی با قید مفهوم‌سازی کرد. فرض کنید $J$ مجموعه کارها، $R$ مجموعه منابع و $S$ مجموعه حالت‌های منابع (مانند بیکار، مشغول، تخلیه شده) باشد. زمان‌بند هدف بیشینه‌کردن یک تابع مطلوبیت $U$ است که اولویت کار $p_j$، کارایی منبع $e_{j,r}$ و هزینه $c_r$ را در نظر می‌گیرد: $$\max \sum_{j \in J} \sum_{r \in R} x_{j,r} \cdot U(p_j, e_{j,r}, c_r)$$ با قیود: $$\sum_{j} x_{j,r} \leq C_r \quad \forall r \in R \quad \text{(ظرفیت منبع)}$$ $$\sum_{r} x_{j,r} \leq 1 \quad \forall j \in J \quad \text{(تخصیص کار)}$$ $$x_{j,r} \in \{0,1\} \quad \text{(متغیر تصمیم باینری)}$$ که در آن $x_{j,r}=1$ اگر کار $j$ به منبع $r$ اختصاص یابد. TARDIS امکان‌پذیری تخصیص‌ها را بر اساس حالت بلادرنگ $S$ به صورت پویا مدیریت می‌کند.

نتایج آزمایشی و توصیف نمودار: اگرچه گزیده PDF ارائه شده حاوی نمودارهای عملکرد خاصی نیست، یک ارزیابی معمولی شامل نمودارهای مقایسه‌ای زیر خواهد بود:
۱. توان عملیاتی کار در طول زمان: یک نمودار خطی که تعداد کارهای تکمیل شده در ساعت را در سراسر مخزن فدرال در مقابل خوشه‌های منابع فردی نشان می‌دهد و مزیت تجمیع را نشان می‌دهد.
۲. نقشه حرارتی استفاده از منابع: یک نمایش گریدی که درصد CPU/GPUهای استفاده شده در ارائه‌دهندگان منابع مختلف (مانند KIT، DESY، Bielefeld و غیره) را در طول یک هفته نشان می‌دهد و اثربخشی تعادل بار را برجسته می‌کند.
۳. CDF تأخیر راه‌اندازی کار: یک نمودار تابع توزیع تجمعی که زمان از ارسال کار تا شروع اجرا را در سیستم فدرال در مقابل ارسال مستقیم به یک سیستم دسته‌ای محلی مقایسه می‌کند و سربار فراسنجش را آشکار می‌سازد.
۴. عملکرد دسترسی به داده: یک نمودار میله‌ای که سرعت خواندن/نوشتن برای داده‌های دسترسی‌شده به صورت محلی، از یک عنصر ذخیره‌سازی فدرال در همان منطقه و از یک عنصر فدرال دور را مقایسه می‌کند و تأثیر کش و شبکه را نشان می‌دهد.

8. چارچوب تحلیل و مدل مفهومی

مطالعه موردی: تحلیل فدرال داده‌های رصد آسمانی
سناریو: یک گروه پژوهشی در Thüringer Landessternwarte Tautenburg نیاز به پردازش ۱ پتابایت داده تصویری از Sloan Digital Sky Survey (SDSS) برای شناسایی خوشه‌های کهکشانی دارد، که یک وظیفه محاسباتی فشرده است و به حدود ۱۰۰،۰۰۰ ساعت CPU نیاز دارد.
فرآیند از طریق Compute4PUNCH/Storage4PUNCH:
۱. احراز هویت: پژوهشگر با استفاده از اعتبارنامه مؤسسه خود (از طریق AAI مبتنی بر توکن) وارد PUNCH JupyterHub می‌شود.
۲. محیط نرم‌افزاری: هسته Jupyter notebook آنها از یک تصویر کانتینر میزبانی شده روی CVMFS اجرا می‌شود که حاوی تمام بسته‌های نجوم لازم (Astropy، SExtractor و غیره) است.
۳. تعریف و ارسال کار: آنها یک کار جاروی پارامتر را در notebook تعریف می‌کنند. notebook از یک کتابخانه کلاینت PUNCH استفاده می‌کند تا اینها را به عنوان یک DAG (گراف غیرمدور جهت‌دار) HTCondor به مخزن فدرال ارسال کند.
۴. تطبیق منابع و اجرا: COBalD/TARDIS نیازمندی‌های کار (CPU، حافظه، احتمالاً GPU) را ارزیابی می‌کند و آنها را به اسلات‌های موجود در سراسر، برای مثال، مخازن HTC در KIT، صف‌های HPC در دانشگاه Bielefeld و گره‌های ابری در DESY خلبانی می‌کند. کارها داده‌های ورودی را از طریق فضای‌نام XRootD فدرال از نزدیک‌ترین مکان ذخیره‌سازی می‌خوانند و احتمالاً از یک کش استفاده می‌کنند.
۵. تجمیع نتایج: فایل‌های خروجی به ذخیره‌سازی فدرال بازنویسی می‌شوند. پژوهشگر پیشرفت را از طریق یک داشبورد وب یکپارچه نظارت می‌کند و در نهایت نتایج را در notebook خود برای تحلیل تجمیع می‌کند.
این مورد، یکپارچه‌سازی بی‌درز هویت، محاسبه، ذخیره‌سازی و مدیریت نرم‌افزار را نشان می‌دهد.

9. کاربردهای آینده و نقشه راه توسعه

زیرساخت PUNCH4NFDI زمینه را برای چندین کاربرد پیشرفته فراهم می‌کند:
۱. آموزش یادگیری ماشین فدرال: مخزن منابع ناهمگن، شامل خوشه‌های GPU بالقوه، می‌تواند از چارچوب‌های آموزش ML توزیع‌شده مانند PyTorch یا TensorFlow در مرزهای مؤسسه‌ای پشتیبانی کند و نیازهای آموزشی حفظ حریم خصوصی را که در آن داده‌ها نمی‌توانند متمرکز شوند، مورد توجه قرار دهد.
۲. تحلیل و بصری‌سازی تعاملی: تقویت سرویس JupyterHub با ابزارهای بصری‌سازی تعاملی مقیاس‌پذیر و قدرتمند شده توسط بک‌اند (مانند ویجت‌های Jupyter متصل به خوشه‌های Dask روی فدراسیون) برای کاوش مجموعه داده‌های بزرگ.
۳. یکپارچه‌سازی با ابرهای خارجی و مراکز HPC: گسترش مدل فدراسیون برای گنجاندن اعتبارات ابر تجاری (مانند AWS، GCP) یا مراکز ابررایانه‌ای ملی (مانند JUWELS در JSC) از طریق یک لایه صورتحساب/حسابداری مشترک، و ایجاد یک ابر ترکیبی واقعی برای علم.
۴. یکپارچه‌سازی فراداده و دریاچه داده: فراتر رفتن از فدراسیون ساده فایل به یک معماری دریاچه داده یکپارچه، که در آن لایه ذخیره‌سازی با یک کاتالوگ فراداده یکپارچه (مانند مبتنی بر Rucio یا iRODS) جفت می‌شود و امکان کشف داده و ردیابی مبدأ در جوامع مختلف را فراهم می‌کند.
۵. گردش کار به عنوان سرویس: ارائه سرویس‌های پلتفرم سطح بالاتر مانند REANA (پلتفرم تحلیل تکرارپذیر) یا Apache Airflow بر روی زیرساخت فدرال، که به دانشمندان اجازه می‌دهد خطوط لوله تحلیل پیچیده و تکرارپذیر را بدون مدیریت زیرساخت زیرین تعریف و اجرا کنند.

نقشه راه توسعه احتمالاً بر استحکام بخشیدن به سرویس تولید، گسترش مخزن منابع، یکپارچه‌سازی ابزارهای مدیریت داده پیچیده‌تر و توسعه APIها و SDKهای کاربرپسند برای کاهش مانع پذیرش برای کاربران غیرمتخصص متمرکز خواهد بود.

10. منابع

  1. کنسرسیوم PUNCH4NFDI. (۲۰۲۴). اوراق سفید PUNCH4NFDI. [سند داخلی کنسرسیوم].
  2. Thain, D., Tannenbaum, T., & Livny, M. (2005). Distributed computing in practice: the Condor experience. Concurrency - Practice and Experience, 17(2-4), 323-356. https://doi.org/10.1002/cpe.938
  3. Blomer, J., et al. (2011). Distribution of software in the CernVM file system with Parrot. Journal of Physics: Conference Series, 331(4), 042009. https://doi.org/10.1088/1742-6596/331/4/042009
  4. Giffels, M., et al. (2022). COBalD and TARDIS – Dynamic resource overlay for opportunistic computing. EPJ Web of Conferences, 251, 02009. https://doi.org/10.1051/epjconf/202225102009
  5. همکاری dCache. (۲۰۲۳). dCache: یک سیستم کش‌گذاری داده ذخیره‌سازی توزیع‌شده. بازیابی شده از https://www.dcache.org/
  6. همکاری XRootD. (۲۰۲۳). XRootD: دسترسی با کارایی بالا، مقیاس‌پذیر و تحمل خطا به داده. بازیابی شده از http://xrootd.org/
  7. Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, 160018. https://doi.org/10.1038/sdata.2016.18
  8. Verma, A., et al. (2015). Large-scale cluster management at Google with Borg. Proceedings of the Tenth European Conference on Computer Systems (EuroSys '15). https://doi.org/10.1145/2741948.2741964