Changed Block Tracking چیست و چرا changed block اهمیت دارد


در این مقاله به بررسی changed block و نحوهٔ پیاده‌سازی آن در Kubernetes و CSI می‌پردازیم تا بفهمید چگونه تغییرات بلاک بین دو snapshot را شناسایی و بهینه‌سازی بکاپ‌ها را انجام دهید.

خبر خوب برای تیم‌های DevOps/SRE: پشتیبانی alpha از مکانیزم Changed Block Tracking برای Kubernetes عرضه شد. این قابلیت به CSI storage drivers اجازه می‌دهد تا بلاک‌هایی که بین snapshotها تغییر کرده‌اند را سریع و کم‌هزینه شناسایی کنند، که به معنی بکاپ‌های سریع‌تر و استفاده کمتر از منابع است. 🚀

اگر عجله دارید و می‌خواهید سریع شروع کنید، می‌توانید مستقیم به بخش Getting Started بروید. ✅

Changed Block Tracking چیست؟

Changed Block Tracking سیستمی است که تغییرات روی سطح بلاک بین دو snapshot را ردیابی می‌کند، بدون نیاز به اسکن کامل حجم دیسک. این بهبود در CSI (Container Storage Interface) و همین‌طور در پشتیبانی ذخیره‌سازی در Kubernetes اعمال شده است. با فعال کردن این ویژگی، کلاستر می‌تواند: شناسایی بلاک‌های تخصیص‌یافته در snapshot، مشخص کردن بلاک‌های تغییر کرده بین دو snapshot از یک volume و بهینه‌سازی عملیات بکاپ با تمرکز روی فقط بلاک‌های تغییر یافته را انجام دهد. ⚙️

نکته مهم: در حال حاضر این API فقط برای block volumes قابل استفاده است و برای file volumes پشتیبانی نشده است. CSI drivers که ذخیره‌سازی فایل‌محور مدیریت می‌کنند، فعلاً نمی‌توانند این قابلیت را پیاده‌سازی کنند.

چرا این مهم است برای Kubernetes و بکاپ‌گیری؟

وقتی workloadهای stateful و داده‌های حساس در Kubernetes زیاد می‌شوند، روش‌های بکاپ‌گیری سنتی مشکلاتی ایجاد می‌کنند: پنجره‌های طولانی بکاپ، مصرف بالای شبکه و I/O، و هزینه نگهداری ذخیره‌سازی به‌خاطر بکاپ‌های تکراری. Changed Block Tracking این مشکلات را با فراهم کردن پشتیبانی native برای بکاپ‌های incremental از طریق CSI کاهش می‌دهد؛ یعنی فقط داده‌های تغییر کرده منتقل می‌شوند و زمان و منابع به‌طور چشمگیری کمتر مصرف می‌شود. 💾

اجزای اصلی پیاده‌سازی

این پیاده‌سازی سه جز کلیدی دارد: CSI SnapshotMetadata Service API که از طریق gRPC حجم snapshot و metadata بلاک‌ها را ارائه می‌کند، SnapshotMetadataService که به‌صورت یک CRD در Kubernetes وجود دارد و دسترسی و جزئیات اتصال سرویس metadata را اعلام می‌کند، و External Snapshot Metadata Sidecar که نقش میانی بین CSI driver و برنامه‌های بکاپ را ایفا می‌کند و رابط gRPC استاندارد را فراهم می‌کند.

الزامات پیاده‌سازی — مسئولیت‌های Storage Provider

اگر در نقش توسعه‌دهنده integration ذخیره‌سازی برای Kubernetes هستید و می‌خواهید Changed Block Tracking را پشتیبانی کنید، باید: RPCهای CSI مربوط به SnapshotMetadata را مطابق protobufهای CSI پیاده‌سازی کنید (از جمله server-side streaming برای GetMetadataAllocated و GetMetadataDelta)، مطمئن شوید بک‌اند ذخیره‌سازی قابلیت ردیابی تغییرات بلاکی را دارد، external-snapshot-metadata sidecar را مستقر کنید، SnapshotMetadataService را به‌صورت یک CRD ثبت و یک نمونه از آن را در کلاستر ایجاد کنید، و مدیریت خطاها را طبق مشخصات CSI انجام دهید.

الزامات پیاده‌سازی — مسئولیت‌های Backup Solution

اگر برنامه بکاپ شما می‌خواهد از این ویژگی استفاده کند، باید: احراز هویت را فراهم کند (دسترسی به Kubernetes ServiceAccount token برای استفاده از SnapshotMetadataService API)، دسترسی‌های لازم RBAC را تنظیم کند، کلاینتی برای streaming gRPC بنویسد که GetMetadataAllocated و GetMetadataDelta را پیاده‌سازی کند و پاسخ‌های server-side streaming را به‌صورت بهینه پردازش نماید. همچنین باید پیام SnapshotMetadataResponse را با مدیریت خطا مناسب پردازش کند. مخزن external-snapshot-metadata در GitHub یک package iterator مفید دارد که پیاده‌سازی کلاینت را ساده‌تر می‌کند. طراحی کلاینت باید توانایی مدیریت استریم‌های بزرگ metadata را داشته باشد تا برای حجم‌های داده‌ای با تغییرات زیاد هم کارا باشد. 🧩

بهینه‌سازی فرایند بکاپ: جریان‌های بکاپ را طوری تغییر دهید که تنها بلاک‌های تغییر یافته شناسایی و منتقل شوند؛ این کار باعث کاهش زمان بکاپ و مصرف منابع می‌شود.

Getting started — چطور شروع کنیم

برای استفاده از Changed Block Tracking در کلاستر: مطمئن شوید CSI driver شما از volume snapshots پشتیبانی می‌کند و snapshot metadata capabilities را همراه با external-snapshot-metadata sidecar پیاده‌سازی کرده است؛ SnapshotMetadataService CRD ثبت شده باشد؛ یک SnapshotMetadataService custom resource برای CSI driver وجود داشته باشد؛ و کلاینت‌هایی ساخته شوند که با احراز هویت مناسب (ServiceAccount token) به API دسترسی پیدا کنند. دو تابع اصلی API که باید با آن کار کنید: GetMetadataAllocated برای فهرست‌بندی بلاک‌های تخصیص‌یافته در یک snapshot و GetMetadataDelta برای لیست تغییر بلاک‌ها بین دو snapshot.

قدم بعدی چیست؟

بر اساس بازخورد و میزان استفاده، تیم توسعه Kubernetes قصد دارد پیاده‌سازی CSI Snapshot Metadata را در نسخه‌های بعدی به Beta ارتقا دهد. اگر می‌خواهید تست کنید یا مشارکت کنید، منابع و مستندات رسمی و مخازن پیاده‌سازی در دسترس‌اند.

جایی برای یادگیری بیشتر و مشارکت

مستندات رسمی CSI Developer Documentation، enhancement proposal مربوط به snapshot metadata، مخزن external-snapshot-metadata در GitHub، تعاریف کامل gRPC در schema.proto، و مثال‌هایی مثل snapshot-metadata-lister و نمونه end-to-end با csi-hostpath-driver، همه منابع خوبی برای شروع و بررسی پیاده‌سازی هستند. 📚

چطور مشارکت کنیم؟

این پروژه مثل بقیه قسمت‌های Kubernetes نتیجه همکاری جمعی است. اگر علاقه‌مند به توسعه یا بررسی طراحی CSI و بخش‌های ذخیره‌سازی Kubernetes هستید، به SIG Storage بپیوندید؛ جلسات منظم Working Group مربوط به Data Protection هم هست و استقبال می‌شود. یک تشکر بزرگ هم از مشارکت‌کنندگان پروژه بابت بازبینی و کمک به طراحی و پیاده‌سازی. 🙏