IBM, Storage

Politika Temelli Snapshot ve Immutability – FlashCopy 2.0 ile beraber

Policy-management-01-1024x1024-1 Politika Temelli Snapshot ve Immutability – FlashCopy 2.0 ile beraber

Bu yazımda sizlere FlashCopy 2.0’dan aslında bir özelliğin kullanımı hakkında bilgi vermeye çalışacağım. Virtulize’ın 8.5.1’in de kullanılmaya başlayan ve 8.5.2 de geliştirilmiş olan Snapshot ve Immutability yetenekleri ana konumuz olacak.

FlashCopy Hakkında

İlk olarak, Snaphotlar FlashCopy’den yararlanır. Yani, Snaphotlar tarafından kullanılan temel teknoloji, yıllardır sahip olduğumuz FlashCopy ile aynıdır. Snapshot ve daha doğru bir isim vermek gerekirse, Volume Grup Snapshot, karmaşıklığı gizleyerek ve günlük anlık görüntü alma görevlerini basitleştirerek, zaman alıcı ve bazen sancılı ön yapılandırma görevlerini basitçe ortadan kaldırır.

FlashCopy, komut dosyası, süreç vb. yatırımlar ve teknolojinin kendisi boşa gitmez, teknolojiyi desteklemeye ve kullanmaya devam edeceğiz, ancak yeni kurulumlar veya güncellenen süreç, basitleştirme ve entegrasyon kolaylığından yararlanmak için Snapshot yönetim yapılarına geçmek isteyebilir.

FlashCopy, yaklaşık 19+ yıl önce Spectrum Virtualize’ın 1. sürümünden beri kullanılmaktadır. Zengin özelliklere sahiptir ve çok sayıda farklı zaman noktası kopyaları, artımlı, basamaklı, çok hedefli, ters, yedeklemeler oluşturmak için kullanılabilir. Ancak sonuç olarak, çok hedefli topolojileri basamaklandırmanız ve “yanlış olanı” durdurmanız veya silmeniz durumunda hızla karmaşık ve özellikle zahmetli hale gelebilir… Bağımlılık zincirleri birçok kullanıcının “beklenmedik” sonuçlara sahip olmasına neden olmuştur.

Volume Group Snaphot (VGS)

Tüm bunlar bizi Volume Grup Snapshotlarının (VGS) kullanıma sunulmasına götürüyor. Bir Volume Grubu, yeni Snapshot yönetiminin merkezinde yer alır. Bir Volume Grubu oluşturun, Volume Grubunuza birden çok Volume (vdisk) ekleyin ve ardından Volume Grubunun belirli bir zamanda bir kopyasını yapın – ve işte, artık bir Volume Grup Snapshotlarınız var.

Bu kadar basit, hedef vdiskler ve flash kopya eşlemeleri ile uğraşmanıza gerek yok. Snapshot oluşturulduğunda Volume Grup’unda bir Volume varsa, VGS’de o Volume karşılık gelen eşdeğer bir Volume Grup Snapshot’ı oluşturulur.

Screenshot-2023-06-02-at-15.09.41-1024x275 Politika Temelli Snapshot ve Immutability – FlashCopy 2.0 ile beraber

VGS’nin oluşturulduğu tarih, saat ve ımmutable olup olmadığı gibi bazı öznitelikleri vardır.

Screenshot-2023-06-02-at-16.50.26 Politika Temelli Snapshot ve Immutability – FlashCopy 2.0 ile beraber

Immutability ve Tutarlılık

VGS’de oluşturan zamandaki noktayı temsil eden veriler her zaman sabittir ve Snapshot içindeki tüm Volumeler karşılıklı olarak tutarlıdır.

Başka bir deyişle, bir VGS içindeki veriler her zaman değişmezdir, ancak VGS’nin kendisi silinebilir.

Hem verilerin değişmezliğine hem de VGS nesnesinin kendisine (Korumalı Kopya olarak kullanmak için) sahip olan Korumalı bir VGS oluşturmak istiyorsanız, VGS’nin değişmez veya oluşturulduğunda “Korumalı” olmasını seçebilirsiniz.

Clone ve Thin-Clone

Bir VGS’nin içeriği değiştirilemez olduğundan, VGS içinde depolanan verilerin zaman içindeki kopyasına erişmek istiyorsanız, bir Klonlama veya Thin Klonlama için kaynak olarak VGS’yi kullanmanız gerekir. Bu yine basit bir VGS’nin Klonlanmasını veya Thin Klonlanmasını istemektir, bunu temelde üçüncü bir Volume Grubuna sahip olarak düşünebilirsiniz.

Adından da anlaşılacağı gibi bir Klon, VGS nokta içi zaman verilerinin tam bir kopyasını oluşturur ve sonunda VGS’nin kendisinden bağımsız olacaktır.

Bir Thin-Clone, ölçülü olarak sağlanır, bu nedenle eriştiğiniz kopya, yalnızca Thin-Clone Volume Group’un kendisinde güncelleyebileceğiniz veya üzerine yazabileceğiniz verileri içerir. Bu nedenle, gerçekten büyümez veya daha fazla alan tüketmez. Tüm değişiklikler VGS’nin kendisinde saklanır. Bu, arka plan kopyasını 0’a (NOCOPY) ayarlamakla eşdeğerdir.

Screenshot-2023-06-02-at-16.50.34-1024x722 Politika Temelli Snapshot ve Immutability – FlashCopy 2.0 ile beraber

Bir VGS’nin birden çok Klonunu veya Thin Klonunu oluşturabilirsiniz. Tıpkı bir Volume Grubunun birden çok VGS’sini oluşturabileceğiniz gibi.

Politika Bazlı Yönetim

8.5.1 ve 8.5.2’deki güncellemelerle nihayet bir Snapshot takvimi uygulayabilir hale geldik. Yani, VGSler için yerleşik bir zamanlayıcımız var (maalesef 🙁 bu, geriye doğru FlashCopy’ye kadar uzanmıyor). Bu, bir Snapshot Politikası belirlemenizi sağlar.

İlkeye bir ad verilebilir, yeni VGS’nin oluşturulma sıklığını ve bunların ne kadar süreyle saklanacağını siz tanımlarsınız. Tutma, normal anlık görüntü oluşturma işleminizin tüm kapasitenizle kaçmamasını sağlamanıza olanak tanır.

Kesin bir başlangıç tarihi ve saati de tanımlayabilirsiniz. Böylece örneğin bir yedekleme veya arşiv işi vb. kaynağı olarak kullanmak için her gece saat 20:00’de günlük bir VGS oluşturulacak şekilde programlayabilirsiniz.

Bu zamanlayıcının kullanılması, yalnızca kilitlenmeyle(crash consistent) tutarlı VGS sağlar. Yani, yeni bir VGS’nin tetiklenmesini sarmak için pre/son komut dosyalarını çalıştırmanıza izin vermiyoruz.

Screenshot-2023-06-02-at-16.14.42-1024x661 Politika Temelli Snapshot ve Immutability – FlashCopy 2.0 ile beraber

Snapshots kullanarak Safeguarded Copy

Yukarıdaki ekran görüntüsünde “Safeguarded” kutusunun işaretlendiğini göreceksiniz, bu daha önce açıkladığım gibi VGS’nin kendisini sabit hale getirir. Politikanın saklama süresine bağlı olarak bu VGS’leri yalnızca sistem temizleyebilir veya silebilir.

Diğer birçok ilke gibi, bu İlkeyi Volume Grubuna uygulamanız yeterlidir ve Grup, İlkede tanımlanan programa göre otomatik olarak VGS oluşturmaya başlayacaktır. Daha önce yaptığınız gibi bir Child Pool deposu oluşturmanıza gerek yoktur. Anlık Görüntü Birimleri, Kaynak Birimi ile aynı Havuzda oluşturulur. Bu nedenle, Bir Volume Grubu farklı havuzlardan Birimler içerebilir ve Volume Snapshotları otomatik olarak işlenir. Volume Grubu Snapshot verileri doğası gereği değiştirilemez olduğundan, artık ayrı bir Child Pool’a ihtiyaç yoktur.

Kalan Önemli Bilgiler

Tek bir Volume Grubunda en fazla 512 Volume ve Sistem başına en fazla 1024 Volume Grubu bulunabilir. Ancak, tek bir Volume Grubuna yüzlerce Volume eklememe konusunda uyarıyorum sizleri. Disk düzeyinde tutarlılığı korumak için verileri önbellekten temizlemesi gereken temel FlashCopy duraklatma ve hazırlama işlemi, yüzlerce Volume’ü tutarlı bir şekilde sürdürülmesi gerekiyorsa serileştirilmiş gecikmelere yol açabilir. Bu durumda Volume sayısını azaltmayı düşünün.

Şu anda, kurtarmak için bir Snapshotlardan kaynağa geri dönmek için “yerinde geri alma” yoktur. Bu, bir Klon Volume Grubuna yeniden eşleme yapılarak elde edilebilir.

Bir Volume Grubuna bir Volume eklerseniz, Volume Grubunun bir sonraki Snapshot’ını aldığınızda, yeni Volume Snapshot’ı içerecektir. Eski Snapshotlar geçerliliğini ve kullanılabilirliğini korur, artık kaynak Volume Grubunun içeriğiyle tutarlı olmadıklarını ancak yine de korunduklarını belirtmek için bir işaretleri vardır.

Tartışılan diğer bir kullanım durumu, mevcut bir Klonlama/Thin Klonlama Volume Grubunu yeniden kullanma yeteneğidir – bugün bir Klonlama/Thin Klonlama oluşturduğunuzda, her zaman yeni Volumelerle yeni bir Volume Grubu oluşturacaktır. Bu, bir yedekleme veya arşiv tipi iş yükü için bir hazırlama alanıysa ve geliştirme ekibi burada neler yapılabileceğini araştırıyorsa, mevcut Volume (örneğin, Hostlarla zaten eşlenmiş olan) yeniden kullanabilmeniz güzel bir ek olacaktır.

Snapshotların, günümüzde FlashCopy tarafından sağlanan tüm işlevselliğin yerini alması amaçlanmadığını belirtmekte fayda var, sık tekrarlanan görevler için bir basitleştirme ve zaman içinde kopyaları iş otomasyon süreçlerinize entegre etmenin basit bir yolunu sağlamanın bir yolu olarak amaçlanıyorlar.

Umarım bilgilendirici bir yazı olmuştur.

Kaynakça:

IBM hakkındaki diğer yazılarım için lütfen BURAYA tıklayınız.

Bir yanıt yazın