نظرة عامة على Azure page blobs

يوفر Azure Storage ثلاثة أنواع من تخزين blob، هي: Block Blobs، وAppend Blobs، وpage blobs. تتكون Block blobs من كتل وهي مثالية لتخزين النصوص أو الملفات الثنائية، وتحميل الملفات الكبيرة بكفاءة. تتكون Append blobs أيضًا من كتل، ولكنها مُحسَّنة لعمليات الإلحاق، مما يجعلها مثالية لسيناريوهات التسجيل. تتكون Page blobs من صفحات بحجم 512 بايت يصل حجمها الإجمالي إلى 8 تيرابايت وهي مصممة لعمليات القراءة/الكتابة العشوائية المتكررة. Page blobs هي أساس Azure IaaS Disks. تركز هذه المقالة على شرح ميزات page blobs ومزاياها.

Page blobs هي مجموعة من صفحات بحجم 512 بايت، والتي توفر القدرة على قراءة/كتابة نطاقات عشوائية من البايت. وبالتالي، تعتبر Page blobs مثالية لتخزين بُنى البيانات المستندة إلى الفهرس والمتفرقة مثل أقراص البيانات ونظام التشغيل للأجهزة الظاهرية وقواعد البيانات. على سبيل المثال، فإن Azure SQL DB تستخدم page blobs كتخزين ثابت أساسي لقواعد البيانات الخاصة بها. علاوة على ذلك، غالبًا ما تُستخدم page blobs أيضًا للملفات ذات التحديثات المستندة إلى النطاق.

تتمثل الميزات الرئيسية لـ Azure page blobs في واجهة REST، وقدرة التخزين الأساسي على الصمود، وإمكانات الترحيل السلس إلى Azure. تتم مناقشة هذه الميزات بمزيد من التفصيل في القسم التالي. بالإضافة إلى ذلك، يتم حاليًا دعم Azure page blobs على نوعين من التخزين: التخزين المتميز والتخزين القياسي. تم تصميم التخزين المتميز خصيصًا لأحمال العمل التي تتطلب أداءً عاليًا متسقًا وزمن انتقال منخفضًا مما يجعل page blobs المتميزة مثالية لسيناريوهات التخزين عالي الأداء. تعد حسابات التخزين القياسي أكثر فعالية من حيث التكلفة لتشغيل أحمال العمل غير الحساسة لزمن الانتقال.

القيود

يمكن لـ Page blobs استخدام طبقة الوصول Hot فقط، ولا يمكنها استخدام طبقات Cool أو Archive. لمزيدٍ من المعلومات حول طبقات الوصول، راجع طبقات الوصول Hot وCool وArchive لبيانات blob.

حالات استخدام العينات

دعنا نناقش حالتين من حالات الاستخدام لـ page blobs التي تبدأ بـ Azure IaaS Disks. Azure page blobs هي المكون الرئيسي للنظام الأساسي للأقراص الظاهرية لـ Azure IaaS. يتم تنفيذ كل من أقراص البيانات ونظام التشغيل Azure كأقراص ظاهرية حيث يتم الاحتفاظ بالبيانات بشكل دائم في النظام الأساسي Azure Storage ثم يتم تسليمها إلى الأجهزة الظاهرية لتحقيق أقصى قدر من الأداء. يتم الاحتفاظ بأقراص Azure بتنسيق VHD لـ Hyper-V ويتم تخزينها على هيئة page blob في Azure Storage. بالإضافة إلى استخدام الأقراص الظاهرية للأجهزة الظاهرية لـ Azure IaaS، تعمل page blobs أيضًا على تمكين سيناريوهات النظام الأساسي كخدمة (PaaS) وقاعدة البيانات كخدمة (DBaaS) مثل خدمة Azure SQL DB، التي تستخدم حاليًا page blobs لتخزين بيانات SQL، مما يتيح عمليات القراءة والكتابة العشوائية السريعة لقاعدة البيانات. مثال آخر هو أنه إذا كان لديك خدمة PaaS للوصول إلى الوسائط المشتركة لتطبيقات تحرير الفيديو التعاونية، فإن page blobs تتيح الوصول السريع إلى المواقع العشوائية في الوسائط. كما أنها تتيح التحرير والدمج السريع والفعال للوسائط نفسها من قبل العديد من المستخدمين.

نفذت خدمات Microsoft التابعة للجهة الحالية مثل Azure Site Recovery وAzure Backup بالإضافة إلى العديد من مطوري الجهات الخارجية ابتكارات رائدة في المجال باستخدام واجهة REST الخاصة بـ page blob. فيما يلي بعض السيناريوهات الفريدة التي تم تنفيذها في Azure:

  • إدارة اللقطات التزايدية الموجهة بواسطة التطبيق: يمكن للتطبيقات الاستفادة من لقطات page blob وواجهات برمجة تطبيقات REST لحفظ نقاط تحقق التطبيق دون تكبد تكرار مكلف للبيانات. يدعم Azure Storage اللقطات المحلية لـ page blobs، والتي لا تتطلب نسخ blob بأكملها. تتيح واجهات برمجة تطبيقات اللقطات العامة هذه أيضًا الوصول إلى دلتا ونسخها بين اللقطات.
  • الترحيل المباشر للتطبيق والبيانات من بيئة محلية إلى السحابة: انسخ البيانات المحلية واستخدم واجهات برمجة تطبيقات REST للكتابة مباشرة إلى Azure page blob أثناء استمرار تشغيل الجهاز الظاهري المحلي. بمجرد أن يتم التقاط الهدف، يمكنك تجاوز الفشل بسرعة إلى جهاز ظاهري لـ Azure باستخدام تلك البيانات. وبهذه الطريقة، يمكنك ترحيل الأجهزة الظاهرية والأقراص الظاهرية من بيئة محلية إلى السحابة بأقل وقت تعطل نظرًا لأن ترحيل البيانات يحدث في الخلفية أثناء الاستمرار في استخدام الجهاز الظاهري وسيكون وقت التعطل اللازم لتجاوز الفشل قصيرًا (بالدقائق).
  • الوصول المشترك المستند إلى SAS، والذي يتيح سيناريوهات مثل القراء المتعددين والكاتب الواحد مع دعم التحكم في التزامن.

يتم إيقاف الأقراص غير المدارة، للحصول على التفاصيل، راجع ترحيل أقراص Azure غير المدارة بحلول 30 سبتمبر 2025.

التسعير

كلا النوعين من التخزين المقدم مع page blobs لهما نموذج تسعير خاص بهما. تتبع page blobs المتميزة نموذج تسعير الأقراص المُدارة، في حين تتم فوترة page blobs القياسية على الحجم المستخدم ومع كل معاملة. لمزيدٍ من المعلومات، راجع صفحة تسعير Azure Page Blobs.

ميزات الكائن الكبير الثنائي الحجم للصفحة

REST API

ارجع إلى المستند التالي للبدء في التطوير باستخدام page blobs. كمثال، راجع كيفية الوصول إلى page blobs باستخدام Storage Client Library for .NET.

يوضح الرسم التخطيطي التالي العلاقات العامة بين الحساب والحاويات وpage blobs.

لقطة شاشة تعرض العلاقات بين الحساب والحاويات والكائنات الثنائية كبيرة الحجم للصفحة

إنشاء page blob فارغة بحجم محدد

أولاً، احصل على مرجع إلى حاوية. لإنشاء page blob، قم باستدعاء أسلوب GetPageBlobClient، ثم قم باستدعاء أسلوب PageBlobClient.Create. قم بتمرير الحد الأقصى لحجم blob المراد إنشاؤها. يجب أن يكون هذا الحجم أحد مضاعفات 512 بايت.

long OneGigabyteAsBytes = 1024 * 1024 * 1024;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

var blobContainerClient =
    blobServiceClient.GetBlobContainerClient(Constants.containerName);

var pageBlobClient = blobContainerClient.GetPageBlobClient("0s4.vhd");

pageBlobClient.Create(16 * OneGigabyteAsBytes);

تغيير حجم page blob

لتغيير حجم page blob بعد الإنشاء، استخدم أسلوب تغيير الحجم. يجب أن يكون الحجم المطلوب أحد مضاعفات 512 بايت.

pageBlobClient.Resize(32 * OneGigabyteAsBytes);

كتابة الصفحات إلى page blob

لكتابة الصفحات، استخدم الأسلوب PageBlobClient.UploadPages.

pageBlobClient.UploadPages(dataStream, startingOffset);

يتيح لك ذلك كتابة مجموعة متسلسلة من الصفحات تصل إلى 4 ميغابايت. يجب أن تبدأ الإزاحة التي تتم الكتابة إليها عند حد 512 بايت (startingOffset % 512 == 0)، وتنتهي عند حد 512 - 1.

بمجرد أن ينجح طلب الكتابة لمجموعة متسلسلة من الصفحات في خدمة blob ويتم نسخه نسخًا متماثلاً من أجل القدرة على الصمود والمرونة، يتم تثبيت الكتابة، ويتم إرجاع النجاح مرة أخرى إلى العميل.

يوضح الرسم التخطيطي أدناه عمليتي كتابة منفصلتين:

رسم تخطيطي يوضح خياري الكتابة المنفصلين.

  1. عملية كتابة تبدأ عند الإزاحة 0 بطول 1024 بايت
  2. عملية كتابة تبدأ عند الإزاحة 4096 بطول 1024 بايت

قراءة الصفحات من page blob

لقراءة الصفحات، استخدم الأسلوب PageBlobClient.Download لقراءة نطاق من وحدات البايت من page blob.

var pageBlob = pageBlobClient.Download(new HttpRange(bufferOffset, rangeSize));

يتيح لك ذلك تنزيل blob الكاملة أو نطاق وحدات البايت بدءًا من أي إزاحة في blob. عند القراءة، لا يلزم أن تبدأ الإزاحة بأحد مضاعفات 512. عند قراءة وحدات بايت من صفحة NUL، تقوم الخدمة بإرجاع صفر بايت.

يوضح الشكل التالي عملية قراءة بإزاحة 256 وحجم نطاق 4352. يتم تمييز البيانات التي تم إرجاعها باللون البرتقالي. يتم إرجاع الأصفار لصفحات NUL.

رسم تخطيطي يوضح عملية قراءة مع إزاحة 256 وحجم نطاق 4352

إذا كان لديك blob مملوءة بشكل ضئيل، فقد ترغب فقط في تنزيل مناطق الصفحات الصالحة لتجنب الدفع مقابل خروج صفر بايت ولتقليل زمن انتقال التنزيل.

لتحديد الصفحات المدعومة بالبيانات، استخدم PageBlobClient.GetPageRanges. يمكنك بعد ذلك تعداد النطاقات التي تم إرجاعها وتنزيل البيانات في كل نطاق.

IEnumerable<HttpRange> pageRanges = pageBlobClient.GetPageRanges().Value.PageRanges;

foreach (var range in pageRanges)
{
    var pageBlob = pageBlobClient.Download(range);
}

تأجير page blob

تقوم عملية تأجير Blob بإنشاء تأمين على blob وإدارته لعمليات الكتابة والحذف. هذه العملية مفيدة في السيناريوهات التي يتم فيها الوصول إلى page blob من عملاء متعددين لضمان أن عميلاً واحدًا فقط يمكنه الكتابة إلى blob في كل مرة. على سبيل المثال، تستفيد أقراص Azure من آلية التأجير هذه لضمان إدارة القرص بواسطة جهاز ظاهري واحد فقط. يمكن أن تتراوح مدة التأمين من 15 إلى 60 ثانية، أو يمكن أن تكون غير محدودة. راجع الوثائق هنا لمزيد من التفاصيل.

بالإضافة إلى واجهات برمجة تطبيقات REST الثرية، توفر page blobs أيضًا وصولاً مشتركًا وقدرة على الصمود وأمانًا محسّنًا. وسنتناول تلك المزايا بمزيد من التفصيل في الفقرات التالية.

الوصول المتزامن

تتيح واجهة برمجة تطبيقات REST الخاصة بـ page blobs وآلية التأجير الخاصة بها للتطبيقات الوصول إلى page blob من عملاء متعددين. على سبيل المثال، لنفترض أنك بحاجة إلى إنشاء خدمة سحابية موزعة تشارك عناصر التخزين مع عدة مستخدمين. يمكن أن تكون تطبيق ويب يقدم مجموعة كبيرة من الصور للعديد من المستخدمين. أحد الخيارات لتنفيذ ذلك هو استخدام جهاز ظاهري مع الأقراص المرفقة. تشمل الجوانب السلبية لذلك، (1) القيد المتمثل في أنه لا يمكن إرفاق القرص إلا بجهاز ظاهري واحد، مما يحد من قابلية التوسع والمرونة ويزيد من المخاطر. إذا كانت هناك مشكلة في الجهاز الظاهري أو الخدمة قيد التشغيل على الجهاز الظاهري، فعندئذ بسبب التأجير، يتعذر الوصول إلى الصورة حتى انتهاء مدة التأجير أو إلغائه؛ و(2) التكلفة الإضافية للحصول على جهاز ظاهري لخدمة تأجير البنية التحتية (Iaas).

هناك خيار بديل وهو استخدام page blobs مباشرة عبر واجهات برمجة تطبيقات REST لـ Azure Storage. يلغي هذا الخيار الحاجة إلى الأجهزة الظاهرية المكلفة لخدمة تأجير البنية التحتية (Iaas)، ويوفر المرونة الكاملة للوصول المباشر من عملاء متعددين، ويبسط نموذج التوزيع الكلاسيكي من خلال القضاء على الحاجة إلى إرفاق/فصل الأقراص، ويزيل مخاطر حدوث مشكلات في الجهاز الظاهري. كما أنه يوفر المستوى نفسه من الأداء الذي يوفره القرص لعمليات القراءة/الكتابة العشوائية

القدرة على الصمود وقابلية الوصول العالية

التخزين القياسي والمميز هو تخزين دائم حيث يتم دائما نسخ بيانات كائن ثنائي كبير الحجم للصفحة لضمان المتانة وقابلية الوصول العالية. قدمت Azure باستمرار متانة على مستوى المؤسسة لأقراص IaaS والكائنات الثنائية كبيرة الحجم للصفحات، مع معدل فشل سنوي صفر بالمائة رائد في الصناعة.

لمزيد من المعلومات حول تكرار Azure Storage لحسابات التخزين القياسية والمميزة، راجع تكرار تخزين Azure، وهذان القسمان على وجه التحديد:

الترحيل السلس إلى Azure

بالنسبة للعملاء والمطورين المهتمين بتنفيذ حل النسخ الاحتياطي المخصص الخاص بهم، يقدم Azure أيضًا لقطات تزايدية لا تحتوي إلا على دلتا. تعمل هذه الميزة على تجنب تكلفة النسخة الكاملة الأولية، مما يقلل بشكل كبير من تكلفة النسخ الاحتياطي. إلى جانب القدرة على قراءة البيانات التفاضلية ونسخها بكفاءة، تعد هذه إمكانية قوية أخرى تتيح المزيد من الابتكارات من المطورين، مما يؤدي إلى تجربة النسخ الاحتياطي والإصلاح بعد كارثة (DR) الأفضل في فئتها على Azure. يمكنك إعداد حل النسخ الاحتياطي أو الإصلاح بعد كارثة الخاص بك لأجهزتك الظاهرية على Azure باستخدام Blob Snapshot جنبًا إلى جنب مع واجهة برمجة تطبيقات Get Page Ranges وواجهة برمجة تطبيقات Incremental Copy Blob، والتي يمكنك استخدامها لنسخ البيانات التزايدية للإصلاح بعد كارثة بسهولة.

علاوة على ذلك، فإن العديد من المؤسسات لديها أحمال عمل هامة قيد التشغيل بالفعل في مراكز البيانات المحلية. لترحيل حمل العمل إلى السحابة، سيكون أحد المخاوف الرئيسية هو مقدار وقت التعطل اللازم لنسخ البيانات، وخطر حدوث مشكلات غير متوقعة بعد التبديل. في كثير من الحالات، يمكن أن يشكل وقت التعطل عائقًا أمام الترحيل إلى السحابة. باستخدام واجهة برمجة تطبيقات REST لـ page blobs، يعالج Azure هذه المشكلة من خلال تمكين الترحيل إلى السحابة بأقل قدر من التعطيل لأحمال العمل الهامة.

للحصول على أمثلة حول كيفية التقاط لقطة وكيفية استعادة page blobمن لقطة، يرجى الرجوع إلى مقالة إعداد عملية نسخ احتياطي باستخدام لقطات تزايدية.