درباره نویسنده
Lanzhou He، مهندس توسعه ارشد Volcengine Edge Computing، مسئول انتخاب فناوری، توسعه و SRE ذخیره سازی لبه است. زمینه های تحقیقاتی عمده ذخیره سازی توزیع شده و ذخیره سازی توزیع شده است. همچنین از طرفداران جامعه منبع باز بومی ابری است.
Volcengine یکی از شرکت های تابعه ByteDance است که خدمات مبتنی بر ابر را ارائه می دهد. Edge Rendering، محصول Volcengine Edge Cloud می‌تواند به کاربران کمک کند تا به برنامه‌ریزی آسان میلیون‌ها کار فریم رندر، زمان‌بندی وظایف رندر نزدیک، و رندر رندر موازی چند وظیفه‌ای چند گرهی دست یابند که کارایی رندر را تا حد زیادی بهبود می‌بخشد.
01 چالش های ذخیره سازی برای محاسبات لبه
در اینجا یک مرور مختصر از مشکلات پیش آمده در رندر لبه ارائه شده است.
- ذخیره سازی شی و فراداده سیستم فایل یکپارچه نیستند، و بنابراین، داده ها را نمی توان مستقیماً از طریق POSIX پس از آپلود از طریق ذخیره سازی شی دستکاری کرد.
- نمی تواند نیازهای سناریوهای با توان عملیاتی بالا، به ویژه هنگام خواندن را برآورده کند.
- رابط S3 API و POSIX به طور کامل پیاده سازی نشده اند.
برای حل مشکلات ذخیره سازی در رندر لبه، تیم تقریباً نیمی از سال را صرف انجام آزمایش های انتخاب ذخیره سازی کرد. در ابتدا، تیم یک جزء ذخیره سازی داخلی را انتخاب کرد که نیازهای ما را از نظر پایداری و عملکرد نسبتاً به خوبی برآورده می کرد.
وقتی صحبت از موارد محاسبات لبه می شود، دو مشکل خاص وجود دارد.
- اولاً، اجزای داخلی برای IDC طراحی شده‌اند و نیازمندی‌های بالایی برای مشخصات دستگاه دارند که برآورده کردن آنها دشوار است.
- دوم، کل اجزای ذخیره‌سازی شرکت با هم بسته‌بندی می‌شوند، از جمله ذخیره‌سازی شی، ذخیره‌سازی بلوک، ذخیره‌سازی توزیع‌شده، ذخیره‌سازی فایل، و غیره، در حالی که سمت لبه عمدتاً به ذخیره‌سازی فایل و ذخیره‌سازی اشیا نیاز دارد که نیاز به تنظیم و اصلاح دارد. علاوه بر این، دستیابی به ثبات نیازمند تلاش است.
بر اساس آن مشکلات، تیم Volvengine پس از بحث به راه حلی عملی رسید: دروازه CephFS + MinIO، با MinIO که رابط ذخیره سازی اشیاء را فراهم می کند، و نتیجه نهایی برای CephFS نوشته می شود. موتور رندر CephFS را برای عملیات رندر سوار می کند. در طول آزمایش و اعتبارسنجی، عملکرد CephFS با تاخیرهای گاه به گاه زمانی که فایل ها به سطح 10 میلیون رسید، شروع به کاهش کرد که نیازهای کاربران داخلی را برآورده نمی کرد.
پس از بیش از سه ماه آزمایش، ما به چندین مورد نیاز اصلی برای ذخیره سازی در رندر لبه رسیدیم:
- عملیات و نگهداری ساده (O&M): توسعه دهندگان ذخیره سازی می توانند به راحتی با اسناد O&M شروع به کار کنند. توسعه آینده و مدیریت خاموش باید به اندازه کافی ساده باشد.
- قابلیت اطمینان داده بالا: از آنجایی که سرویس ذخیره سازی را مستقیماً به کاربران ارائه می دهد، داده های نوشته شده را نمی توان از دست داد یا دستکاری کرد.
- استفاده از یک موتور ابرداده واحد برای پشتیبانی از ذخیره سازی اشیاء و ذخیره سازی فایل: با از بین بردن نیاز به بارگذاری و دانلود چندین بار پیچیدگی را کاهش می دهد.
- عملکرد بهتر برای خواندن: بهبود عملکرد خواندن زیرا خواندن بسیار بیشتر از نوشتن اتفاق می افتد.
- فعالیت جامعه: یک جامعه فعال به معنای توسعه سریعتر است و در هنگام بروز مشکلات مفیدتر است.
02 چرا JuiceFS
تیم Volcengine Edge Storage در سپتامبر 2021 از JuiceFS مطلع شد و با تیم Juicedata ارتباط برقرار کرد. پس از آن، Volcengine تصمیم گرفت JuiceFS را امتحان کند.
آنها با آزمایش PoC در محیط آزمایش شروع کردند که عمدتاً بر ارزیابی امکان سنجی، پیچیدگی عملیات و استقرار، پذیرش برنامه و اینکه آیا نیازهای برنامه را برآورده می کند یا خیر، تمرکز کردند.
دو مجموعه از محیط ها مستقر شده اند، یکی بر اساس Redis تک گره به همراه Ceph، و دیگری بر روی یک MySQL تک نمونه ای به همراه Ceph.
روند کلی استقرار بسیار روان است زیرا Redis، MySQL و Ceph (که از طریق Rook مستقر شده اند) نسبتاً بالغ هستند، مستندات برای استقرار جامع است و مشتری JuiceFS می تواند به راحتی با این پایگاه داده ها و Ceph کار کند.
از نظر پذیرش برنامه، Edge Cloud مبتنی بر توسعه و استقرار بومی ابری است. در حالی که JuiceFS از S3 API پشتیبانی می کند، کاملاً با پروتکل POSIX سازگار است و همچنین Kubernetes CSI را پشتیبانی می کند که به طور کامل نیازهای برنامه Edge Cloud را برآورده می کند.
پس از آزمایش جامع، JuiceFS به طور کامل با نیازهای طرف پذیرش برنامه مطابقت داشت. همچنین می‌توان آن را مستقر کرد و در تولید اجرا کرد تا نیازهای آنلاین سمت پذیرش برنامه را برآورده کند.
بهینه سازی فرآیند برنامه
قبل از استفاده از JuiceFS، رندر لبه عمدتاً از سرویس ذخیره سازی اشیاء داخلی (TOS) ByteDance استفاده می کرد، که در آن کاربران داده ها را در TOS آپلود می کنند، موتور رندر فایل ها را به محلی دانلود می کند، فایل های محلی را می خواند، نتایج رندر ایجاد می کند، و سپس نتایج را به TOS بارگذاری می کند. و در نهایت، کاربران نتایج رندر را از TOS دانلود می کنند. فرآیند کلی شامل بسیاری از درخواست‌های شبکه و کپی داده‌ها می‌شود، بنابراین هر گونه لرزش شبکه یا تأخیر زیاد در فرآیند بر تجربه کاربر تأثیر می‌گذارد.
پس از استفاده از JuiceFS، جریان داده بسیار ساده شده است: آپلود کاربر از طریق دروازه JuiceFS S3. از آنجایی که JuiceFS از S3 و POSIX API پشتیبانی می‌کند، می‌توان آن را مستقیماً روی موتور رندر نصب کرد که فایل‌ها را از طریق POSIX می‌خواند و می‌نویسد، به طوری که کاربر نهایی نتایج رندر را مستقیماً از دروازه JuiceFS S3 دانلود می‌کند و روند کلی را مختصرتر می‌کند. و کارآمد، و همچنین پایدارتر.
شتاب خواندن فایل، شتاب نوشتن متوالی فایل های بزرگ
به لطف مکانیسم کش در مشتری JuiceFS، می‌توانیم فایل‌های مکرر خوانده شده را در موتور رندر کش ذخیره کنیم، که سرعت خواندن را تا حد زیادی افزایش می‌دهد. تست مقایسه ما نشان می دهد که استفاده از کش می تواند توان عملیاتی را حدود 3-5 برابر افزایش دهد.
به طور مشابه، از آنجایی که مدل نوشتن JuiceFS ابتدا به حافظه متعهد می‌شود، زمانی که یک قطعه (پیش‌فرض 64M) پر است، یا زمانی که برنامه close() یا fsync() را فراخوانی می‌کند، سپس داده‌ها در ذخیره‌سازی شی آپلود می‌شوند، و فراداده فایل پس از آپلود موفقیت آمیز داده ها به روز می شود. بنابراین هنگام نوشتن فایل های حجیم ابتدا روی حافظه نوشته می شوند و سپس روی دیسک باقی می مانند که می تواند سرعت نوشتن فایل های حجیم را تا حد زیادی بهبود بخشد.
سناریوی فعلی Edge عمدتاً رندر است، که در آن سیستم فایل بسیار بیشتر از نوشتن می خواند و فایل های نوشته شده معمولاً بزرگ هستند. JuiceFS به خوبی با این سناریوها مطابقت دارد.
03 نحوه استفاده از JuiceFS در Edge Storage
JuiceFS در درجه اول در Kubernetes مستقر شده است، با DaemonSet که مسئول نصب سیستم فایل JuiceFS و سپس ارائه hostPath برای رندر کردن موتور پادها است. اگر نقطه اتصال از کار بیفتد، DaemonSet وظیفه بازیابی خودکار نقطه اتصال را بر عهده می گیرد.
از نظر کنترل مجوز، Edge Storage هویت گره های خوشه JuiceFS را از طریق LDAP احراز هویت می کند و هر مشتری JuiceFS با LDAP از طریق کلاینت LDAP احراز هویت می کند.
04 تجربه عملی در محیط تولید ذخیره سازی JuiceFS
موتورهای فراداده
JuiceFS از بسیاری از پایگاه های داده به عنوان موتورهای ابرداده (مانند MySQL، Redis) پشتیبانی می کند. MySQL در محیط تولید برای Volcengine Edge Storage استفاده می شود زیرا MySQL از نظر عملیات، قابلیت اطمینان داده ها و تراکنش ها عملکرد بهتری دارد.
MySQL در حال حاضر از استقرار تک نمونه ای و چند نمونه ای (یک استاد، دو slave) استفاده می کند که برای سناریوهای مختلف Edge انعطاف پذیر است. در محیط هایی با منابع کم، می توان از استقرار تک نمونه ای با توان عملیاتی MySQL نسبتاً پایدار استفاده کرد. هر دو سناریو استقرار از دیسک ابری با کارایی بالا (ارائه شده توسط Ceph cluster) به عنوان ذخیره سازی داده MySQL استفاده می کنند که امنیت داده ها را تضمین می کند.
در یک سناریوی غنی از منابع، می توانید یک استقرار چند نمونه ای را تنظیم کنید. همگام سازی master-slave نمونه های متعدد توسط مؤلفه ارکستراتور ارائه شده توسط اپراتور MySQL به دست می آید. تنها در صورتی سالم در نظر گرفته می شود که همه دو نمونه برده با موفقیت همگام شوند. با این حال، از آنجایی که مهلت زمانی نیز تنظیم شده است، اگر همگام سازی به موقع کامل نشود، زنگ هشدار را راه اندازی می کند. هنگامی که راه حل بازیابی فاجعه بعدا آماده شد، ممکن است از دیسک محلی به عنوان ذخیره سازی داده MySQL برای بهبود بیشتر عملکرد خواندن و نوشتن، کاهش تأخیر و بهبود توان استفاده کنیم.
پیکربندی تک نمونه MySQL
منابع کانتینری
- CPU: 8C
- حافظه: 24G
- دیسک: 100G (بر اساس Ceph RBD، ابرداده برای میلیون‌ها فایل حدود 30 گیگ نیاز دارد)
- تصویر کانتینر: mysql:5.7
MySQL my.cnf پیکربندی
ignore-db-dir=lost+found # delete هنگام استفاده از MySQL 8.0 و بالاتر.
حداکثر اتصال = 4000
innodb-buffer-pool-size=12884901888 # 12G
ذخیره سازی اشیا
ما از یک خوشه Ceph به عنوان ذخیره سازی اشیا استفاده می کنیم که از طریق Rook مستقر می شود و در حال حاضر محیط تولید از انتشار Octopus استفاده می کند. با Rook، خوشه‌های Ceph را می‌توان به روشی ابری اداره کرد و نگهداری کرد، و اجزای Ceph از طریق Kubernetes مدیریت می‌شوند، که پیچیدگی استقرار و مدیریت خوشه Ceph را تا حد زیادی کاهش می‌دهد.
پیکربندی سخت افزار سرور Ceph:
- سی پی یو 128 هسته ای
- 512 گیگابایت رم
- دیسک سیستم: 2T * 1 NVMe SSD
- دیسک داده: 8T * 8 NVMe SSD
- پیکربندی نرم افزار سرور Ceph:
سیستم عامل: دبیان 9
- هسته: اصلاح کنید
/proc/sys/kernel/pid_max - نسخه Ceph: اختاپوس
- پشتیبان ذخیره سازی Ceph: BlueStore
- کپی های Ceph: 3
- تنظیم خودکار Placement Group را خاموش کنید
تمرکز اصلی رندر Edge تأخیر کم و عملکرد بالا است، بنابراین از نظر انتخاب سخت افزار، دیسک های SSD NVMe ترجیح داده می شود و Debian 9 به عنوان سیستم عامل انتخاب می شود. تکرار سه گانه برای Ceph پیکربندی شده است زیرا کد پاک کردن در محیط های محاسباتی لبه ممکن است منابع زیادی را اشغال کند.
مشتری JuiceFS
مشتری JuiceFS با Ceph RADOS کار می کند (عملکرد بهتر از Ceph RGW)، اما این ویژگی به طور پیش فرض در باینری رسمی فعال نیست، بنابراین باید مشتری JuiceFS را دوباره کامپایل کنید. ابتدا لیبرادوس باید نصب شود. توصیه می شود نسخه librados را با نسخه Ceph مطابقت دهید. Debian 9 با بسته librados-dev مطابق با نسخه Ceph Octopus (v15.2.*) عرضه نمی شود، بنابراین باید آن را به صورت دستی دانلود کنید.
پس از نصب librados-dev، می توانید شروع به کامپایل مشتری JuiceFS کنید. ما از Go 1.19 برای کامپایل استفاده می کنیم، که می تواند حداکثر تخصیص حافظه را کنترل کند تا در موارد شدید که مشتری JuiceFS حافظه زیادی را اشغال می کند، از OOM جلوگیری کند.
make juicefs.ceph
شما می توانید یک سیستم فایل ایجاد کنید و پس از اتمام کامپایل، JuiceFS را روی گره محاسباتی نصب کنید. لطفاً به مستندات رسمی JuiceFS مراجعه کنید.
05 چشم انداز
JuiceFS یک سیستم ذخیره سازی توزیع شده بومی ابری است که درایور CSI را برای پشتیبانی از روش های استقرار بومی ابری ارائه می دهد. از نظر O&M، JuiceFS انعطاف‌پذیری زیادی را فراهم می‌کند و کاربران می‌توانند به‌صورت ابری یا در محل استقرار را انتخاب کنند. JuiceFS کاملاً با POSIX سازگار است، بنابراین دستکاری فایل ها بسیار راحت است. اگرچه JuiceFS می‌تواند با تأخیر بالا و IOPS کم هنگام خواندن و نوشتن فایل‌های تصادفی کوچک به دلیل ذخیره‌سازی اشیا به عنوان ذخیره‌سازی پشتیبان، دارای مزیت بزرگی در سناریوهای فقط خواندنی (یا خواندنی فشرده) است که متناسب با نیازهای برنامه است. سناریوهای رندر لبه بسیار خوب است.
همکاری آینده بین Volcengine Edge Cloud و JuiceFS بر جنبه های زیر متمرکز خواهد بود.
-
ابر بومی تر: Volvengine در حال حاضر از JuiceFS از طریق hostPath استفاده می کند و بعداً ممکن است برای سناریوهای مقیاس پذیری الاستیک به JuiceFS CSI Driver تغییر مکان دهد.
-
ارتقاء موتور فراداده: خدمات ابرداده را به یک سرویس gRPC استخراج کنید و قابلیت‌های کش چند سطحی را برای عملکرد بهتر در سناریوهای خواندنی فراهم می‌کند. موتور ابرداده اصلی ممکن است برای مقیاس‌بندی بهتر در مقایسه با MySQL به TiKV مهاجرت کند.
-
ویژگی‌های جدید و رفع اشکال: برای سناریوی فعلی، برخی از ویژگی‌ها اضافه می‌شوند و برخی از باگ‌ها برطرف می‌شوند، ما انتظار داریم که در روابط عمومی به جامعه کمک کنیم و به جامعه بازگردانیم.
از JuiceFS/Juicedata!
