Capacity Tier (эсвэл бидний Vim дотор гэж нэрлэдэг - captir) нь Veeam Backup and Replication 9.5 Update 4-ийн өдрүүдэд Archive Tier нэрээр гарч ирсэн. Үүний цаад санаа нь үйл ажиллагааны сэргээх гэж нэрлэгддэг цонхноос унасан нөөцлөлтийг объектын хадгалалт руу шилжүүлэх боломжтой болгох явдал юм. Энэ нь дискний зай багатай хэрэглэгчдэд зориулсан зайг цэвэрлэхэд тусалсан. Мөн энэ сонголтыг Move Mode гэж нэрлэдэг байсан.

Энэхүү энгийн (мэдэгдэж байгаа юм шиг) үйлдлийг гүйцэтгэхийн тулд хоёр нөхцөлийг хангахад хангалттай байсан: зөөгдсөн нөөцөөс авсан бүх цэгүүд нь UI-д тодорхой заасан дээр дурдсан үйлдлийн сэргээх цонхны хил хязгаараас гадуур байх ёстой. Хоёрдугаарт: гинж нь "битүүмжилсэн хэлбэр" (битүүмжилсэн нөөц гинж эсвэл идэвхгүй нөөц гинж) байх ёстой. Энэ нь цаг хугацааны явцад энэ хэлхээнд ямар ч өөрчлөлт гарахгүй гэсэн үг юм.

Гэхдээ VBR v10-д уг үзэл баримтлалыг шинэ функцүүдээр баяжуулсан - Хуулбарлах горим, Битүүмжилсэн горим болон дуудахад хэцүү Immutability нэртэй зүйл гарч ирэв.

Эдгээр нь бидний өнөөдрийн ярих сонирхолтой зүйлүүд юм. Эхлээд VBR9.5u4 дээр хэрхэн ажиллаж байсан тухай, дараа нь арав дахь хувилбарын өөрчлөлтүүдийн талаар.

Мөн цэвэр хэлний аваргууд намайг өршөөгөөч, гэхдээ орчуулж болохгүй нэр томьёо хэтэрхий олон байна.
Тиймээс энд англиизм олон тонн байх болно.
Бас маш олон gif.
Мөн зургууд.

• Өчүүхэн ч харамсахгүйгээр. Нийтлэлийн зохиогч.

Байсан шиг

За, үйл ажиллагааны сэргээх цонх болон битүүмжилсэн нөөцлөлт (эсвэл тэдгээрийг Идэвхгүй нөөц гинжин хэлхээний баримт бичигт нэрлэсэн) шинжилж эхэлцгээе. Тэдний ойлголтгүй бол нэмэлт тайлбар хийх боломжгүй.

Зурган дээр харж байгаагаар бид өгөгдлийн блок бүхий нэг төрлийн нөөц сүлжээтэй бөгөөд энэ нь чадавхийн түвшний холбогдсон репозиторийн SOBR гүйцэтгэлийн түвшин дээр байрладаг. Манай нөөц цонх гурван өдөр байна.

Үүний дагуу даваа гаригт үүсгэсэн .vbk нь өмнөх гинжийг битүүмжилж, цонхыг гурван өдөр болгон тохируулсан. Энэ нь та эдгээр гурван хоногоос өмнөх бүх зүйлийг буудлагын талбай руу аюулгүй тээвэрлэж эхлэх боломжтой гэсэн үг юм.

Гэхдээ битүүмжилсэн гинж гэж яг юу гэсэн үг вэ, 4-р шинэчлэлтийн хүчин чадалтай буудлагын талбай руу юу илгээж болох вэ?

Forward Incremental, гинжийг битүүмжлэх шинж тэмдэг нь шинэ бүрэн нөөцийг бий болгох явдал юм. Энэ бүрэн нөөцлөлтийг хэрхэн авах нь хамаагүй: синтетик бүрэн болон идэвхтэй бүрэн нөөцлөлтийг хоёуланг нь авч үздэг.

Урвуу тохиолдолд эдгээр нь бүгд үйлдлийн цонхонд ордоггүй файлууд юм.

Буцалттай урагшлах өсөлтийн хувьд эдгээр нь бүгд буцаалт ба .vbk, хэрэв гүйцэтгэлийн хэмжээнд өөр .vbk байгаа бол.

Одоо нөөц хуулбарын сүлжээнүүдтэй ажиллах сонголтыг авч үзье. Зөвхөн GFS-ийн хадгалалтад хамаарах зүйлсийг энд тээвэрлэсэн. Учир нь сүүлийн үеийн нөөц хуулбарын сүлжээнд хадгалагдсан бүх зүйл нэг талаараа өөрчлөгдөж болно.

Одоо бүрээсний доор харцгаая. Тэнд шингэн алдалт гэж нэрлэгддэг процесс явагддаг - хэмжээн дээр хоосон нөөц файлуудыг үлдээж, эдгээр файлуудаас блокуудыг багтаамжийн буудлагын хүрээ рүү чирэх. Энэ процессыг оновчтой болгохын тулд шингэн алдалтын индекс гэж нэрлэгддэг индексийг ашигладаг бөгөөд энэ нь хүчин чадалтай буудлагын зайд аль хэдийн хуулсан блокуудыг хуулбарлахаас зайлсхийх боломжийг олгодог.

Энэ нь ямар байхыг жишээгээр харцгаая: Бид гүйлгээний цонхноос гарч ирсэн, битүүмжилсэн гинжин хэлхээнд хамаарах .vbk байна гэж бодъё. Үүнийг даацын буудлагын талбай руу шилжүүлэх бүрэн эрхтэй гэсэн үг. Зөөх үед шилжүүлсэн файлын багтаамжийн зураас болон блокуудад мета өгөгдлийн файл үүсдэг. Холбоосын түвшний мета өгөгдлийн файл нь манай файл ямар блокуудаас бүрдэхийг тайлбарладаг. Зураг дээрх тохиолдолд бидний эхний файл нь a, b, c блокуудаас бүрдэх ба мета өгөгдөл нь эдгээр блокуудын холбоосыг агуулдаг. Бидэнд шилжихэд бэлэн, a, b, d блокуудаас бүрдэх хоёр дахь .vbk файл байгаа үед бид шингэн алдалтын индексийг шинжлэхдээ зөвхөн d блокыг шилжүүлэх шаардлагатай гэдгийг ойлгодог. Мөн түүний мета өгөгдлийн файл нь өмнөх хоёр блок болон нэг шинэ блокийн холбоосыг агуулна.

Үүний дагуу эдгээр хоосон зайг мэдээллээр дүүргэх үйл явцыг шингэн сэлбэх гэж нэрлэдэг. Энэ нь орон нутгийн гүйцэтгэлийн хэмжээнд хамгийн эртний .vbk файл дээр суурилсан өөрийн шингэн сэлбэх индексийг аль хэдийн ашигладаг. Өөрөөр хэлбэл, хэрэв хэрэглэгч хүчин чадалтай буудлагын хүрээнээс файлыг буцаахыг хүсвэл бид эхлээд хамгийн эртний бүрэн нөөцлөлтийн блокуудын индексийг үүсгэж, зөвхөн дутуу блокуудыг багтаамжийн буудлагын галерейгаас шилжүүлнэ. Зурган дээр үзүүлсэн тохиолдолд, FullBackup1.vbk-ийг шингэн сэлбэх индексийн дагуу нөхөн сэргээхийн тулд бид зөвхөн багтаамжийн буудлагын талбайгаас авдаг C блок хэрэгтэй. Хадгалах үүл объект нь хүчин чадалтай буудлагын талбай болж үйлчилдэг бол энэ нь танд асар их мөнгө хэмнэх боломжийг олгоно.

Эндээс харахад энэ технологи нь WAN хурдасгуурт ашигладагтай ижил юм шиг санагдаж болох ч энэ нь зөвхөн тийм юм шиг санагдаж байна. Хурдасгуурт давхардлын хуваалт нь глобал шинж чанартай байдаг ба энд файл бүрийн дотор локал давхардал нь тодорхой офсет дээр ашиглагддаг. Энэ нь шийдэгдэж буй даалгавруудын ялгаанаас шалтгаална: энд бид том хэмжээний бүрэн нөөц файлуудыг хуулах хэрэгтэй бөгөөд бидний судалгаагаар тэдгээрийн хооронд урт хугацаа өнгөрсөн ч гэсэн энэхүү хуулбарлах алгоритм нь хамгийн сайн үр дүнг өгдөг.

Гэхдээ индексийн бурхны хувьд илүү олон индекс! Мэдээлэл сэргээх индекс бас байдаг! Хүчин чадлын зураасанд байрлах машиныг сэргээж эхлэхэд бид зөвхөн гүйцэтгэлийн зураасанд байхгүй өвөрмөц өгөгдлийн блокуудыг унших болно.

Яаж ийм болсон юм

Танилцуулгын хэсэг л энэ. Энэ нь нэлээд нарийвчилсан боловч дээр дурьдсанчлан эдгээр дэлгэрэнгүй мэдээлэлгүйгээр шинэ функцууд хэрхэн ажилладагийг тайлбарлах боломжгүй юм. Тиймээс, олон зүйл нуршилгүйгээр эхнийх рүүгээ орцгооё.

Хуулах горим

Энэ нь үндсэндээ одоо байгаа технологид суурилсан боловч огт өөр хэрэглээний логикийг агуулдаг. 

Энэ горимын зорилго нь орон нутгийн хэмжээнд байгаа бүх өгөгдөл хүчин чадлын зураасанд хуулбартай байхыг баталгаажуулах явдал юм.

Хэрэв та Зөөх болон Хуулах горимуудыг шууд харьцуулбал дараах байдалтай харагдана.

• Зөвхөн битүүмжилсэн гинжийг хөдөлгөж болно. Хуулбарлах горимын хувьд нөөцлөх ажилд юу тохиолдохоос үл хамааран бүх зүйлийг шилжүүлдэг.
• Файлууд үйлдлийн нөөцлөх цонхны хил хязгаараас хэтэрсэн тохиолдолд зөөх, нөөц файл гарч ирмэгц хуулбарлах ажиллагаа идэвхждэг.
• Хуулбарлах шинэ өгөгдлийг хянах нь байнга явагддаг бөгөөд зөөхөд 4 цаг тутамд нэг удаа идэвхждэг.

Шинэ горимыг авч үзэхдээ би энгийн жишээнээс нарийн төвөгтэй жишээ рүү шилжихийг санал болгож байна.

Хамгийн түгээмэл тохиолдолд, бид зүгээр л шинэ файлуудыг нэмэгдүүлсэн, бид зүгээр л хүчин чадалтай буудлагын мужид хуулж авдаг. Нөөцлөх ажилд ямар горимыг ашиглахаас үл хамааран энэ нь гинжин хэлхээний битүүмжилсэн хэсэгт хамаарах эсэхээс үл хамааран, бидний үйлдлийн цонхны хугацаа дууссан эсэхээс үл хамааран. Тэд зүгээр л аваад хуулж авсан.

Үүний цаад үйл явц нь дээр дурдсанчлан шингэн алдалт хэвээр байна. Хуулбарлах горимд энэ нь бидний санах ойд байгаа блокуудыг хуулахгүй байх боломжийг олгодог. Цорын ганц ялгаа нь хэрэв кино горимд бид жинхэнэ файлуудыг хуурамч файлаар сольсон бол энд бид тэдэнд ямар ч байдлаар хүрэхгүй бөгөөд бүх зүйлийг байгаагаар нь үлдээдэг. Үгүй бол энэ нь яг л шингэн алдалтын индекс бөгөөд таны мөнгө, цагийг хэмнэхийг хичээдэг.

Асуулт гарч ирнэ - хэрэв та UI-г харвал хоёр сонголтыг нэгэн зэрэг сонгох боломжтой. Ийм хосолсон горим хэрхэн ажиллах вэ?

Үүнийг зөв болгоё.

Эхлэл нь стандарт: нөөц файлыг үүсгээд шууд хуулж авдаг. Үүн дээр нэмэгдэл үүсгээд бас хуулна. Энэ нь файлууд бидний үйлдлийн цонхноос гарч, битүүмжилсэн гинж гарч ирэх хүртэл тохиолддог. Энэ үед бид шингэн алдалтын ажиллагааг хийж, эдгээр файлуудыг хуурамч файлаар солино. Мэдээжийн хэрэг, бид хүчин чадалтай буудлагын талбай руу дахин юу ч хуулахгүй.

Энэ бүх гайхалтай логик нь интерфэйс дэх ганцхан нүдийг хариуцдаг: Нөөцлөлтийг үүсгэгдсэн даруйдаа объектын хадгалах сан руу хуулж ав.

Бидэнд яагаад энэ Хуулбарлах горим хэрэгтэй байна вэ?

Асуултыг ингэж өөрчилсөн нь дээр: түүний тусламжтайгаар бид ямар эрсдэлээс хамгаалагдсан бэ? Энэ нь бидэнд ямар асуудлыг шийдвэрлэхэд тусалдаг вэ?

Хариулт нь тодорхой байна: мэдээжийн хэрэг, энэ бол өгөгдлийг сэргээх явдал юм. Хэрэв бид объектын санах ойн локал мэдээллийн бүрэн хуулбартай бол манай бүтээгдэхүүнд юу тохиолдсоноос үл хамааран бид нөхцөлт Амазон дахь файлуудаас өгөгдлийг сэргээх боломжтой.

Тиймээс хамгийн энгийнээс эхлээд нарийн төвөгтэй хувилбаруудыг авч үзье.

Бидний толгой дээр тохиолдож болох хамгийн энгийн золгүй явдал бол нөөц сүлжээн дэх файлуудын аль нэг нь нэвтрэх боломжгүй байх явдал юм.

Хамгийн гунигтай түүх бол манай SOBR хадгалах сангийн нэг хэсэг нь эвдэрсэн явдал юм.

SOBR репозитор бүхэлдээ нэвтрэх боломжгүй болсон ч буудлагын талбай ажиллаж байгаа үед энэ нь бүр дордох болно.
Бүх зүйл үнэхээр муу байна - энэ бол нөөц сервер үхэж, таны анхны хүсэл бол арван минутын дараа Канадын хил рүү гүйх явдал юм.

Одоо нөхцөл байдал бүрийг тусад нь авч үзье.

Бид нэг (тэр ч байтугай хэд хэдэн) нөөц файлаа алдсан үед бидний хийх ёстой зүйл бол репозиторыг дахин хайх процессыг эхлүүлэх бөгөөд алдагдсан файлыг хуурамч файлаар солих болно. Мөн шингэн сэлбэх процессыг ашиглан (энэ тухай өгүүллийн эхэнд ярилцсан) хэрэглэгч хүчин чадалтай буудлагын хүрээнээс өгөгдлийг орон нутгийн хадгалах сан руу татаж авах боломжтой болно.

Одоо байдал илүү төвөгтэй болсон. Манай SOBR нь Гүйцэтгэлийн горимд ажилладаг хоёр экстентээс бүрддэг гэж бодъё, энэ нь бидний .vbk болон .vib нь тэдгээр дээр нэлээд жигд бус давхаргаар тархсан гэсэн үг юм. Хэзээ нэгэн цагт өргөтгөлүүдийн аль нэг нь боломжгүй болж, хэрэглэгч өгөгдлийн нэг хэсэг нь яг энэ хэмжээнд байгаа машиныг яаралтай сэргээх шаардлагатай болдог.

Хэрэглэгч сэргээх шидтэнг ажиллуулж, сэргээхийг хүссэн цэгээ сонгох ба шидтэн ажиллаж байхдаа орон нутгийн хэмжээнд сэргээхэд шаардлагатай бүх өгөгдөл байхгүй тул хүчин чадлын зураг авалтаас татаж авах шаардлагатай байгааг ойлгодог. галерей. Үүний зэрэгцээ дотоод санах ойд үлдсэн блокуудыг үүлнээс татаж авахгүй. Сэргээх индексийн алдар суу (тиймээ, энэ тухай өгүүллийн эхэнд дурдсан байсан).

Энэ хэргийн нэг дэд төрөл бол SOBR репозиторыг бүхэлд нь ашиглах боломжгүй болсон явдал юм. Энэ тохиолдолд бидэнд локал сангаас хуулах зүйл байхгүй бөгөөд бүх блокуудыг үүлнээс татаж авдаг.

Хамгийн сонирхолтой нөхцөл байдал бол нөөц сервер үхсэн явдал юм. Энд хоёр сонголт байна: админ нь гайхалтай бөгөөд тохиргооны нөөцлөлт хийсэн, админ нь өөрөө муу Пиноккио бөгөөд тохиргооны нөөцлөлт хийгээгүй.

Эхний тохиолдолд түүнд VBR-ийн цэвэр суулгацыг хаа нэг газар байрлуулж, стандарт хэрэгслийг ашиглан мэдээллийн санг нөөцлөлтөөс сэргээхэд хангалттай. Энэ үйл явцын төгсгөлд бүх зүйл хэвийн байдалдаа орно. Эсвэл дээрх хувилбаруудын аль нэгийн дагуу сэргээх болно.

Гэхдээ хэрэв админ нь өөрийн дайсан юмуу эсвэл тохиргооны нөөц нь баатарлаг бүтэлгүйтсэн бол энд ч гэсэн бид түүнийг хувь тавилангийн өршөөлд үлдээхгүй. Энэ тохиолдолд бид Import Object Storage хэмээх шинэ журмыг нэвтрүүлсэн. Энэ нь танд SOBR репозиторыг гараар дахин үүсгэх үйл явцыг алгасаж, дараа нь дахин хайлт хийх замаар багтаамжийн буудлагын хүрээг хавсаргах, Vim интерфэйс дээр хадгалах объект нэмж, Импортын хадгалах сангийн процедурыг ажиллуулах боломжийг олгоно. Та болон таны нөөцлөлтүүдийн хооронд саад болох цорын ганц зүйл бол хэрэв таны нөөцлөлтүүд шифрлэгдсэн бол нууц үг оруулах хүсэлт юм.

Энэ нь магадгүй Хуулбарлах горимын тухай бөгөөд бид цаашаа явна

Битүүмжилсэн горим

Гол санаа нь репозиторын сонгосон SOBR хүрээн дээр шинэ нөөцлөлт гарч ирэх боломжгүй юм. v10-ээс өмнө бид хадгалах газартай ажиллахыг бүрэн хориглодог байсан үед л засвар үйлчилгээний горимтой байсан. Нөөцлөлтийг нэг удаа өөр хэмжээгээр зөөвөрлөхөд зөвхөн Evacuate товчлуурыг ашиглах боломжтой бөгөөд хадгалах санг хаахад зориулагдсан хатуу горим юм.

Битүүмжилсэн горим нь нэг төрлийн "зөөлөн" сонголт юм: бид шинэ нөөцлөлт үүсгэхийг хориглож, сонгосон хадгалалтын дагуу хуучин нөөцийг аажмаар устгадаг боловч энэ явцад бид хадгалагдсан цэгүүдээс сэргээх чадвараа алдахгүй. Бидэнд ашиглалтын хугацаа нь дуусч байгаа техник хангамж байгаа бөгөөд түүнийг солих шаардлагатай болсон, эсвэл зүгээр л илүү чухал зүйлд чөлөөлөх хэрэгтэй болсон ч үүнийг авч, бүгдийг нэг дор зөөх газар байхгүй үед маш хэрэгтэй зүйл юм. Эсвэл устгах боломжгүй.

Үүний дагуу үйл ажиллагааны зарчим нь маш энгийн: бүх бичих үйлдлүүдийг (шинэ өгөгдлийн харагдах байдал), унших (сэргээх) орхих, устгах (хадгалах) зэргийг хориглох шаардлагатай.

Хоёр горимыг нэгэн зэрэг ашиглах боломжтой боловч Засвар үйлчилгээ нь илүү чухал ач холбогдолтой гэдгийг санаарай.

Жишээ болгон хоёр хүрээнээс бүрдэх SOBR-ийг авч үзье. Эхний дөрвөн өдөр бид Forever Forever Incremental горимд нөөцлөлтүүдийг үүсгээд дараа нь хүрээг нь битүүмжилсэн гэж бодъё. Энэ нь бид хоёр дахь боломжит хэмжээгээр шинэ идэвхтэй бүрэн үүсгэх эхлэлийг тавихад хүргэдэг. Хэрэв бидний хадгалалт дөрөв бол битүүмжилсэн хэмжээс дээр байрлах бүх гинж нь түүний хязгаараас хэтэрсэн тохиолдолд цэвэр ухамсартайгаар устгагдах болно.

Устгах нь өмнө нь тохиолддог нөхцөл байдал байдаг. Жишээлбэл, энэ нь үе үе дүүрсэн өсөн нэмэгдэх юм. Хэрэв бид эхний хоёр өдөр бүрэн нөөцлөлт үүсгээд пүрэв гаригт хадгалах газрыг битүүмжилэхээр шийдсэн бол Баасан гарагт шинэ нөөцлөлт үүсгэх үед Даваа гарагийн файл устах болно. энэ хүртэл ямар ч хамаарал байхгүй. Мөн цэг нь өөрөө хэнээс ч хамаарахгүй. Дараа нь бид боломжтой хэмжээнд дөрвөн цэг үүсгэх хүртэл хүлээж, үлдсэн гурвыг нь устгаж, бие биенээсээ хамааралгүйгээр устгана.

Урвуу өсөлттэй бол бүх зүйл илүү хялбар байдаг. Үүнд хамгийн эртний цэгүүд нь юунаас ч хамаардаггүй бөгөөд аюулгүйгээр устгаж болно. Тиймээс шинэ .vbk шинээр үүсгэгдэнгүүт хуучин .vrbs нэг нэгээр нь устах болно.

Дашрамд хэлэхэд, бид яагаад байнга шинэ .vbk үүсгэдэг вэ: хэрвээ бид үүнийг үүсгээгүй, харин хуучин гинжин хэлхээг үргэлжлүүлбэл хуучин .vbk нь ямар ч горимд хязгааргүй удаан хугацаанд хөлдөж, устгахаас сэргийлдэг. Иймд бид талбайг битүүмжилсэн даруйд үнэгүй хэмжээгээр бүрэн нөөцлөлтийг бий болгохоор шийдсэн.

Хүчин чадалтай буудлагын талбайн хувьд бүх зүйл илүү төвөгтэй байдаг.

Эхлээд хуулбарлах горимыг харцгаая. Бид дөрвөн өдрийн турш идэвхтэй нөөцлөлт үүсгэж, дараа нь багтаамжийн буудлагын талбайг битүүмжилсэн гэж бодъё. Бид юу ч устгадаггүй, харин хадгалахыг даруухнаар тэвчиж, дараа нь бид буудлагын талбайн багтаамжаас өгөгдлийг устгадаг.

Хөдөлгөөний горимд ойролцоогоор ижил зүйл тохиолддог - бид засварлахыг хүлээж, хуучин санах ойг локал хадгалалтаас устгаж, объектын санах ойд хадгалагдсаныг устгадаг.

Forever forward incremental-ийн сонирхолтой жишээ. Бид хадгалалтыг гурван цэгт суулгаж, Даваа гарагт нөөцлөлтийг хийж эхэлдэг бөгөөд үүнийг үүлэн дээр байнга хуулдаг. Хадгалах газрыг битүүмжлэсний дараа нөөцлөлтүүдийг үргэлжлүүлэн үүсгэж, гурван цэгийг хадгалах боловч багтаамжийн зураасанд хадгалагдсан өгөгдөл нь хамааралтай хэвээр байгаа бөгөөд устгах боломжгүй. Тиймээс, бид .vbk нь хадгалагдахаас хэтэрсэн пүрэв гараг хүртэл хүлээж, зөвхөн дараа нь бид бүх хадгалсан гинжийг тайван устгана.

Мөн жижиг татгалзал: энд байгаа бүх жишээг нэг машин дээр харуулав. Хэрэв таны нөөцлөлтөд тэдгээрийн хэд хэдэн нь байгаа бол Идэвхтэй Бүрэн хийгдсэн эсэхээс хамаарч засварлах нь өөр байх болно.

Энэ бол үндсэндээ бүх зүйл юм. Тиймээс хамгийн хатуу онцлог руу шилжье -

Үл өөрчлөгдөх чадвар

Өмнөх цэгүүдийн нэгэн адил хамгийн эхний зүйл бол энэ функц ямар асуудлыг шийдэх явдал юм. Бид нөөцлөлтөө хаа нэгтээ хадгалахаар байршуулангуут ​​тэдгээрийн аюулгүй байдлыг хангах, өөрөөр хэлбэл тухайн хадгалалтын явцад устгах, өөрчлөхийг биечлэн хориглох хүсэл эрмэлзэл төрдөг. Үүнд админууд, тэдгээрийн үндсэн бүртгэлүүд багтана. Энэ нь тэдгээрийг санамсаргүй болон санаатай гэмтлээс хамгаалах боломжийг олгодог. AWS-тэй ажилладаг хэн бүхэн Object Lock хэмээх ижил төстэй функцтэй таарсан байх.

Одоо горимыг ерөнхийд нь харцгаая, дараа нь нарийн ширийн зүйлийг авч үзье. Бидний жишээн дээр хувиршгүй байдлыг дөрвөн өдрийн турш хадгалах хүчин чадалтай буудлагын талбайн хувьд идэвхжүүлнэ. Нөөцлөхдөө хуулбарлах горим идэвхжсэн.

Үл хувиршгүй байдал нь ерөнхий хадгалалттай ямар ч байдлаар харьцдаггүй. Жишээлбэл, энэ нь нэмэлт оноо эсвэл бусад зүйлийг нэмдэггүй. Зүгээр л хүн нөөц файлуудаа дөрөв хоногийн дотор устгаж чадахгүй. Хэрэв та Даваа гарагт нөөцлөлт хийвэл түүний файлыг зөвхөн Баасан гарагт устгах боломжтой.

Шингэн алдалт, индекс, мета өгөгдлийн тухай өмнө нь тайлбарласан бүх ойлголтууд яг адилхан ажилласаар байна. Гэхдээ нэг нөхцөлтэйгээр блокыг зөвхөн өгөгдөлд төдийгүй мета өгөгдөлд зориулж тохируулсан болно. Энэ нь зальтай халдагчид бидний мета өгөгдлийн санг устгаж, өгөгдлийн блокуудыг ашиггүй хоёртын тоосонцор болж хувирахаас сэргийлэхийн тулд хийгддэг.

Одоо блок үүсгэх технологийг тайлбарлах сайхан цаг болжээ. Эсвэл блок үүсгэх. Үүнийг хийхийн тулд түүний харагдах байдалд хүргэсэн нөхцөл байдлыг анхаарч үзээрэй.

Зургаан өдрийн хуваарийг авч үзье, мөн түүнээс доош хугацаанд өөрчлөгдөшгүй байдлын хүлээгдэж буй дуусах хугацааг тэмдэглэнэ. Эхний өдөр бид өгөгдлийн блок a болон түүний мета өгөгдлөөс бүрдсэн файлыг авч, үүсгэнэ. Хэрэв өөрчлөгдөшгүй байдлыг гурван өдөр гэж тохируулсан бол дөрөв дэх өдөр өгөгдлийг онгойлгож, устгана гэж үзэх нь логик юм. Хоёр дахь өдөр бид ижил тохиргоотой b блокоос бүрдсэн шинэ файл2-г нэмнэ. Дөрөв дэх өдөр блокыг арилгах шаардлагатай. Гэвч гурав дахь өдөр ямар нэг аймшигтай зүйл тохиолдов - шинэ d блок болон хуучин блок a холбоосоос бүрдсэн File3 файл үүсгэгдсэн. Энэ нь блок болон түүний хувиршгүй байдлын далбааг шинэ огноо руу дахин тохируулах шаардлагатай бөгөөд үүнийг зургаа дахь өдөр рүү шилжүүлнэ гэсэн үг юм. Энд асуудал гарч ирдэг - бодит нөөцлөлтөд ийм блокууд асар олон байдаг. Мөн тэдний өөрчлөгдөхгүй байх хугацааг уртасгахын тулд та маш олон тооны хүсэлт гаргах хэрэгтэй. Үнэн хэрэгтээ энэ нь бараг төгсгөлгүй өдөр тутмын үйл явц байх болно, учир нь бид хуулбар бүрээр давхардсан блокуудын асар их стекийг олох магадлал өндөр байх болно. Объект хадгалах үйлчилгээ үзүүлэгчдийн олон тооны хүсэлт нь юу гэсэн үг вэ? Зөв! Сарын сүүлээр их хэмжээний мөнгө.

Мөн таны дуртай үйлчлүүлэгчдийг их хэмжээний мөнгөөр ​​ил гаргахгүйн тулд блок үүсгэх механизмыг зохион бүтээжээ. Энэ нь бидний тогтоосон өөрчлөгдөшгүй хугацаанд нэмдэг нэмэлт хугацаа юм. Доорх жишээнд энэ хугацаа хоёр өдөр байна. Гэхдээ энэ бол зүгээр л нэг жишээ. Бодит байдал дээр тэд өөрсдийн томъёог ашигладаг бөгөөд энэ нь сар бүр түгжигдэх үед ойролцоогоор арав хоног нэмж өгдөг.

Үүнтэй ижил нөхцөл байдлыг үргэлжлүүлэн авч үзье, гэхдээ блок үүсгэх. Эхний өдөр бид a блок болон мета өгөгдлөөс file1 үүсгэнэ. Бид үүсгэх хугацаа ба хувиршгүй байдлыг нэмдэг - энэ нь файлыг устгах боломж зургаа дахь өдөр болно гэсэн үг юм. Хэрэв хоёр дахь өдөр бид b блок болон a блокийн холбоосоос бүрдсэн File2-г үүсгэвэл устгасан өдөр юу ч болохгүй. Тэр зургаа дахь өдрийнх шигээ зогсож байв. Тиймээс бид хүсэлтийн тоог хэмнэхийг хичээж байна. Эцсийн хугацааг өөрчлөх цорын ганц нөхцөл бол үүсгэх хугацаа дууссан тохиолдолд юм. Өөрөөр хэлбэл, гурав дахь өдөр шинэ File3 нь a хаах холбоосыг агуулж байгаа бол Gen2-ийн хугацаа аль хэдийн дууссан тул 1-р үе нэмэгдэх болно. Мөн блок a-г устгах хүлээгдэж буй огноо найм дахь өдөр рүү шилжинэ. Энэ нь давхардсан блокуудын ашиглалтын хугацааг уртасгах хүсэлтийн тоог эрс багасгах боломжийг олгодог бөгөөд энэ нь үйлчлүүлэгчдэд нэг тонн мөнгө хэмнэдэг.

Энэхүү технологи нь өөрөө S3 болон S3-тэй нийцтэй техник хангамжийн хэрэглэгчдэд боломжтой бөгөөд тэдгээрийн хэрэгжилт нь Amazon-ийнхаас ялгаатай биш гэдгийг үйлдвэрлэгчид баталгаажуулдаг. Тиймээс Azure-г яагаад дэмждэггүй вэ гэсэн хууль ёсны асуултын хариулт - тэдгээр нь ижил төстэй шинж чанартай боловч энэ нь бие даасан объект биш харин савны түвшинд ажилладаг. Дашрамд хэлэхэд Амазон өөрөө объектын түгжээг дагаж мөрдөх ба засаглал гэсэн хоёр горимтой байдаг. Хоёрдахь тохиолдолд, админуудын дээрх хамгийн агуу админ болон root дээрх root нь объектын түгжээг үл харгалзан өгөгдлийг устгасан хэвээр байх болно. Дагаж мөрдөх тохиолдолд бүх зүйл нягт хадаж, хэн ч нөөцлөлтийг устгаж чадахгүй. Амазоны админууд хүртэл (тэдний албан ёсны мэдэгдлийн дагуу). Энэ бол бидний дэмждэг горим юм.

Мөн ердийнх шиг зарим хэрэгтэй холбоосууд:

• дээр Блок үүсгэх нарийн ширийн зүйл бүрээр.
• тухай бүх мэдээлэл Veeam Backup & Replication 10 хамгийн сайнаараа
• О Хүчин чадлын түвшин дэлгэрэнгүй

Эх сурвалж: www.habr.com