IBM Storwize Deduplication & Data Reduction Pools – Derinlemesine İnceleme

Herkese Merhaba

Sonunda Storwize’a 8.1 güncellemesi ile birlikte tekilleştirme geldi ve ücretsiz. Hybrid storage serisinden V5030 ve V7000’de bu özellik yer alıyor. Dosbil Bilgisayar test merkezinde yeni gelen özelliği derinlemesine inceledik.

8.1 versiyonu çıkalı epey oldu fakat Deduplication’ın menüden seçilebilmesi 8.1.3.x ile mümkün olabiliyor. Dolayısıyla 8.1.3.x altında bir sürüm kullanıyorsanız bu özelliği açamamanız olası.

8.1.3.x kullansanız bile storage ilk yapılandırırken Pool oluşturma kısmında Data Reduction seçeneğini işaretlemediyseniz Deduplication veya Thin Reclaimation özelliğini kullanmak mümkün değil.

create pool

IBM tekilleştirmeyi neden bu kadar geç getirdi?

Yazılan veriler 32KB‘lik block’larla işlediği için standart disk havuzu (pool) tekilleştirme gibi alan kazanımı sağlayan teknolojiler için uygun değildi. Çünkü veri 8KB‘lik block’larla yazıldığında çok daha iyi tekilleşiyor ve kontroller ünitesini çok daha az yoruyor. IBM’in bu kriteri değiştirmesi, petabyte’larca cluster’lara sahip müşterileri için pek mümkün gözükmüyordu. Dolayısıyla standart disk havuzunun yanında “Data Reduction Pool” eklenerek tamamen yeni mimaride bir disk havuzu getirildi. Yazının geri kalanında kısaltma için DRP yazacağım.

Aradaki büyüklük farkını şöyle belirtebilirim: Storwize’da oluşturulabilecek;
Max Standart Pool adeti: 1024
Max DRPool adeti: 4

Max Standart Raid Array: 4096
Max DRP Raid Array: 128

O yüzden DRP tamamen yeni bir disk havuzu mimarisi ve aktif iş yüklerinde tekilleştirme açılamaz. Boş yeri çok olan veya HyperSwap cluster mimariler, diğer site üzerindeki standart pool’u silip DRP oluşturarak ve bolca storage vmotion ile taşıma yaparak bu mimariye online geçebilirler.

Altta görüldüğü gibi SAS diskler standart, SSD’ler ise DRP.

pools

DRP oluşturduktan sonra volume oluştururken Thin Provision seçildiğinde “automatic space reclaimation/SCSI Unmap” özelliği açık geliyor. Eğer siz buna ilave olarak diğer yer kazanımı teknolojilerinden Compression veya Deduplication isterseniz açabiliyorsunuz.

create volume

Volume performansını tam olarak test edebilmek için 4 farklı tipte de volume oluşturduk. Bunu yapmaktaki amaç ise volume tipinden bağımsız olarak alabileceğimiz performansı ve tekilleştirmeyi gözlemleyebilmekti.

DRAID6_SSD_TVOL: Thin
DRAID6_SSD_TDVOL: Thin + Deduplicated
DRAID6_SSD_CVOL: Thin + Compressed
DRAID6_SSD_CDVOL: Thin + Compressed + Deduplicated

volumes

Thin Dedup ve Compress Dedup volume’lerine her birine onar adet Windows 2016 Server ISO’su kopyaladık. Bu ISO’ların her biri 5.5 GB.

isolar
Burada dikkat etmemiz gereken nokta ise volume tiplerinin birbirinden farklı olması. Volume’lerden birinde sadece dedup açık, diğerinde ise compression+dedup açık. Dolayısıyla storage üzerinde olan ama farklı tip volume’lerde olan bu verinin tekilleştirileceği benim için merak konusuydu.

Altta görüldüğü üzere toplamda 106 GB yer kaplaması gereken 20 adet ISO dosyası tekilleştirilerek 98 GB yer kazanımı sağlanmış. Yani sadece 8 GB‘lık bir yer kaplıyor volume üzerinde.

20 iso deduplication

Performans Testi:

İşin yer kazanımı konusu sorunsuz fakat performans konusunda da şüphelerim vardı. Bu volume’lerin tamamının IOPS performansını test ettik.

Test Server: Lenovo SR650, 2 x Xeon Silver 4110 – 48 GB Ram
Vmware ESX 6.5.0 Update 1 (Build 7388607)
Test VM: Windows 2016 Server, 1×8 CPU, 24 GB Ram
Test Storage: IBM V5030 – 9×1.96 TB SSD – Distributed RAID6

Altta test sonuçlarının parametrelerini ve detaylarını inceleyebilirsiniz.

                          8k yazma / 8k okuma
Thin Volume: 68.000 / 95.510
Thin+Dedup: 91.020 / 143.050
Compressed: 70.820 / 98.500
Comp+Dedup: 72.820 / 88.780

Compression + Deduplication’ın ikisinin birden aktif edilmesi doğal olarak okumada IOPS kaybına neden oluyor.
Thin Dedup’ın da bu kadar yüksek IOPS’lara çıkması gelen verinin henüz daha diske yazılmadan cache’de tekilleştirilmesinden kaynaklanıyor. Controller sıkıştırmayla uğraşmadığı için IOPS epey yükselmiş.

Kısacası tüm volume tiplerinde 8K IO büyüklüğü ile 68.000 IO üzerinde performans alınabiliyor. Bu da çoğu iş yükü için yeterli bir performans.

tvol

tdvol

cvol

cdvol

Reklamlar

NVMe™ ve NVMe™ over Fabrics Nedir?

NVMe™ neden ortaya çıktı?

SAS ve SATA arabirimleri hem ağır komut setlerine hem de düşük mesaj kuyruklarına sahip olduğu için gelen komutların hepsinin işlenmesi uzun sürüyordu.

NVMe™’de her mesaj kuyruğunda 65.535 komut seti işlenebilirken
SAS’da bu rakam 256, SATA’da ise 32.

Dolayısıyla flash tabanlı depolama birimleri gayet hızlı olmasına rağmen aradaki mesaj komutları maksimum 256 adet işlenebildiği için sistemdeki darboğaz burada oluşuyordu. Bunun yanında NVMe™ komut seti, SCSI komut setine nazaran %50 daha az CPU tüketiyor ve düşük gecikmeye de sahip.

Bunu şuna benzetebiliriz; fabrikamızda çıkan ürünleri ayıran robotlar var ve bu robotun 256 adet kolu var. Dolayısıyla 1 dakika içinde 256 adet ürünü ayırıp ilgili yerlere yerleştirebiliyor. Bu robot kolunun 65.535’e çıkarıldığını düşünün ve tükettiği gücün de %50 azaldığını.

NVMe™ depolama birimini evimizdeki PC’ye veya ofisimizdeki sunucuya da taksak performans iyileştirme mantığı buradan geliyor.

NVMe™ over Fabrics nedir?

NVMe™ bir PC üstündeki memory ile depolama alanını birbiriyle hızlı görüştürmek için yeterli bir teknoloji. Fakat iş birden fazla sunucuyu birbirlerinin memory’sine hızlı ulaştırmaya geldiğinde o zaman araya bir arabirim sokmak zorundayız. Bunun adına da NVMe™ over Fabrics deniyor. Fabrics birden fazla arabirimi içine almış bir şemsiye konumunda. Bu arabirimler ise;

Fibre Channel, InfiniBand, RoCE, iWarp, TCP(geliştiriliyor)

Bu arabirimlerin tamamı NVMe desteğine sahip veya ileride sadece bir firmware güncellemesi ile sahip olacak.

slide7_029

Bir sunucu üzerindeki veriyi storage’lere hızlı iletmek ve veriyi storage’den memory’ye hızlı almak istiyorsak kullanılan arabirim NVMe™ over Fibre Channel.

Fakat amacımız veri analitiği veya yüksek performans gerektiren işlemler (süper bilgisayarlar), dolayısıyla tüm sunucular üzerindeki memory’lerin diğer sunucular tarafından işlenebilmesini istiyorsak RDMA tabanlı diğer alt arabirimlere ihtiyaç duyuluyor. (RoCE, iWarp, InfiniBand)

Ethernet platformundaki hızlar (RoCE, iWarp) artmasına rağmen Fibre Channel üzerindeki kayıpsız, tahmin edilebilen ve tutarlı veri aktarımı nedeniyle iş kritik (mission-critical) uygulamaların Fibre Channel üzerinde kalacağına kesin gözle bakılıyor. O yüzden NVMe™ over Fabrics teknolojisini bu arabirimler üzerinden birbirlerinin önünü kesecek bir teknoloji gibi düşünmemek lazım. Her arabirimin kullanım amacı ve isteklere cevap verdiği alan farklı.

SAN Fibre Channel switchlerde aynı ASIC chip ile FICON, FCP(SCSI) ve NVMe™ veri transferi yapılabiliyor, ekstra bir donanım ihtiyacına gerek yok. Eğer şuanda sisteminizde bulunan fibre host bus adapter GEN6, SAN Switch GEN6 ve depolama ünitesi NVMe™ over Fabrics destekliyor ise veri trafiği arabirimi olarak sistem otomatik olarak FICON yerine NVMe™’i seçiyor.

Performans karşılaştırması olarak bakıldığında ise 12Gbit SAS arabirimli SSD’lere kıyasla;

100% rastgele okuma, NVMe 3x daha fazla IOPS,
70% rastgele okuma, NVMe 2x daha fazla IOPS,
100% rastgele yazma, NVMe 1.5x fazla IOPS,
100% okuma: NVMe 2x daha hızlı,
100% yazma: NVMe 2.5x daha hızlı.

latency.jpg

Üstteki resimde de depolama tiplerinin gecikmeleri yer alıyor. NVMe SCM SSD’ler NAND ve SAS arabirimli SSD’lere nazaran çok daha az gecikmeye sahip.

vocabulary

Üstteki tabloda gözüktüğü gibi yeni teknolojinin gündeme gelmesiyle tabiki bazı isimler de değişecek.

Çoğu storage üreticisinin NVMe™ over Fabrics destekleyen storage’ları yolda, hatta bazılarının satışta bile. Hız gereksinimi olduğunda açıkçası ilerleyen süreçte SCSI arabirimi kullanılmayacak. Ama iş kapasiteye geldiğinde maliyet faktörü göz önüne alındığında SCSI tabanlı en son çıkan 12 TB diskler kullanılmaya devam edecektir.

Traditional RAID vs Distributed RAID

Her sistem yöneticisinin elinin altında ama iyi ama kötü storage’ler (NAS, SAN), her storage’e de takılı diskler var. Bu diskler üzerinde oluşturulmuş da bir RAID yapısı mevcut.

Örneğin: 7 disklik RAID5  (5 data disk, 1 parity disk, 1 spare disk)

Bu disklerin de bir gün arızalanacağı gün gibi açık… Arıza durumunda arızalı diskin (failed disk) içindeki veriler eşitleme diskinden (parity disk) okunmaya başlar ve bu andan itibaren sistem parity disk üzerinden çalışmaya devam eder. Aynı zamanda sistemimizdeki yedek diske (spare disk) de parity diskinden veriler kopyalanmaya başlar. Dolayısıyla parity disk üzerine acayip bir yük biner. Fakat kimsenin pek de bahsetmediği bu operasyonun ne kadar süreceği?

Alttaki tabloda disk kapasiteleri ve arıza durumunda rebuild işleminin % kaç IO harcaması istediği belirtilerek spare diskin aktif edilme süresi belirtiliyor. Görüldüğü üzere 8 TB’lık bir disk arızalandığında geleneksel raid’de spare diskin devreye girme süresi 35 saat olarak belirtilmiş.

distributedraid

Açıkçası o 35 saatlik sürede parity disk üzerine binen bu yük nedeniyle o diskin de arızalanması gayet mümkün. RAID6 kullarak çift parity diskine sahip olabilirsiniz ama bu sefer de performans çok düşük olacak. RAID10 kullanarak kendinizi hız ve güvenlik açısından garantiye alabilirsiniz ama bu sefer de kapasiteden feragat etmeniz gerekecek. Bunun farklı bir çözümü daha var.

IBM, Huawei, HP gibi markalarda farklı isimlerde yer alan çok da yeni olmayan bir RAID teknolojisi: IBM’de Distributed RAID olarak geçiyor. Distributed Parity olarak da adlandırılıyor.

Parity diski ve spare disk için ayrı ayrı birer fiziksel disk ayırmaktansa o disk kapasitesini sistem içerisindeki bütün data disk’lerine yayıyor. Örneğin 7 disklik bir yapıda bir disk arızalandığında sadece parity blokları geri kalan 6 diskteki spare bloklarına aktarılıyor.

draid_04

Böylece sistem tek bir disk üzerinden çalışmak yerine o veri bloklarını 6 diskten okuyarak diski yormuyor.
Arızalı diski yenisiyle değiştirdiğimizde de yine aynı şekilde tek diskten okuyup tek diske yazmak yerine 6 diskten okuyup tek diske veriyi eşitliyor. Dolayısıyla hem arızanın ilk gerçekleştiği anda hem de daha sonrasındaki disk değişimi operasyonunda süreyi kısaltıyor.

4 TB’lık diskin geleneksel RAID ile %50 yükte 24 saatte devreye alındığı biliniyor Distributed RAID ile bu süre 3 saate düşmüş durumda.

Bir diğer avantajı da tüm diskler veri yazma ve okumada kullanıldığı için %5 ila %10 arası performans artışı sağlıyor.

Örneğin Huawei Storage’lerde zaten zorunlu bu teknoloji kullanılıyor fakat IBM’de kullanıcı seçebiliyor. İlerleyen süreçte tüm storage üreticileri buna geçecek ve bence geleneksel RAID hiç kullanılmayacak.

Vmware ESX üzerinde Database Sanallaştırma (SQL, Oracle)

Veritabanı sunucularında özellikle yazılımcıların yönlendirmesi nedeniyle sanallaştırmaya karşı olumsuz bir görüş vardır. Hatta yazılımcının yazdığı yazılımın veritabanı ve uygulama geliştirme platformu sanallaştırma ile ilgili uyumluluk makaleleri yazsa bile yazılımcı kişi/firma sanallaştırma önermiyoruz diyebilecek kadar ileri gidebiliyor.

Fiziksel sunucu tabiki sanallaştırılmış sunucudan biraz daha hızlı ama bu fark küçük ve orta ölçekli işletmeler için tolere edilebilir. O yüzden sanallaştırmanın getirdiği diğer avantajlar kesinlikle performans farkından daha önemli. Tabi sanallaştırılmış ortamlarda da bu yapıyı düzgün kullanabilmek için yapılması gereken birkaç ipucu var. Oracle ve MsSQL ile ilgili makaleleri derleyerek size yapılması gereken adımları açıklamak istiyorum. Altta belirtilen ayarlar her iki veritabanı için de geçerlidir. Sadece yapılması gereken adımları ufak açıklamalarla belirttim. Detaylı açıklama isteyenler alttaki linklerden indirip inceleyebilirler, kesinlikle öneririm.

SQL: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf
Oracle: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-oracle-databases-on-vmware-best-practices-guide.pdf

BIOS UEFI Ayarları

-İşlemcilerin tüm C durumları kapatılmalı (C1E Hata durumu dahil): C-State işlemcinin güç tasarrufu yaptığı durumdur. İşlemci kendini beklemeye aldığı için bu bekleme durumundan dönerken gecikmeye yol açar. Linkte hangi C durumunun hangi işe yaradığı açıklanmış. Hepsinin kapatılması kesinlikle öneriliyor.
-Mümkün olan en son firmware seviyesi kullanılmalı.
-Turbo Boost etkinleştirilmeli.
-Hyper-Threading etkinleştirilmeli.
-Gelişmiş CPU ayarları etkinleştirilmeli (VT-x/AMD-V, EPT, RVI)
-Sunucunun güç ayarları İşletim sistemi kontrol edecek şekilde ayarlanmalı (OS Controlled)

ESX ve VM Güç Ayarları
-ESX Ayarlarındaki güç seçeneği High Performance olarak ayarlanmalı
-DB sanal makinesinin Windows/Linux güç ayarları High Performance olarak ayarlanmalı.

VM İşlemci Ayarları
-Pek çok kişi sanal makinaya atadığı vCPU ve vCore arasındaki farkı bilmiyor. Örneğin SQL Server 2016 Standart Edition maksimum 4 vCPU ve maksimum 24 vCore adresleyebilir.

Yani sanal makineye 6 vCPU, 4 vCore atadığınızda 24 core atadığınızı düşünüyorsunuz ama SQL 4 vCPU üzerindeki 4 çekirdeği çarparak 16 core’u işleyebiliyor. O yüzden bu kural çok önemli.

-Bunun haricinde vNUMA denilen hangi işlemci çekirdeğine hangi iş yükünün gideceğini belirleyen bir kriter de mevcut. Vsphere 6.5 ve sonrasını kullanıyorsanız bu konuda hiçbir şey yapmanıza gerek yok kendisi otomatik en iyisi neyse hesaplayıp onu uyguluyor. ESX 6.5’den öncesini kullanıyorsanız VM’lere CPU atarken alttaki şekilde yapmanız gerekli.

ESX host’taki fiziksel işlemci sayısı: 2
ESX host’taki fiziksel işlemcinin core sayısı: 12
DB sanal makinama verilmesi istenen core sayısı: 16
DB sanal makinam da girilmesi gereken CPU ayarı: 2 vCPU, 8 vCore.

Sanal makineye atayacağım core sayısı fiziksel core sayısından fazla olamaz! Fiziksel core sayısından fazla vermek istiyorsam vCPU çarpanını arttırmam ve core sayısını düşürmem gerekli. Eğer DB sunucumuza 12 core’luk bir kaynak atamak isteseydim 1 vCPU, 12 vCore vermem gerekiyordu.

CPU HotAdd/Plug özelliği devre dışı bırakılmalı: vNUMA’yı devre dışı bırakması nedeniyle işlemciye gidecek talepler düzgün işlenemediği için performans kaybı yaşatıyor. O yüzden bu özelliğin kesinlikle kapatılması isteniyor.

Sanal sunucuların işlemci istatistiklerinde de kaale alacağımız yer ESX’in göstergeleri olacak. Yapılan testlerde sanal sunucunun içinden %15 CPU kullandığını görsenize bile ESX bu değeri %25 olarak gösterebiliyor. Çünkü VM işlemciye veri gönderdiği anda diğer tüm sanal sunucuların performansını düşürüyor. Dolayısıyla ESX istatistikleri diğer sanal sunuculardan DB sanal sunucusuna kaymış işlemci gücünü de içerdiği için doğru veri ancak ESX üzerinden okunabiliyor.

VM Memory Ayarları
-Reserve all guest memory (All locked) işaretlenmeli
-Memory HotAdd tam olarak istenmese de çok iyi analiz edilen yapılarda etkileştirilebilir.

Sanal makinenin kullandığı rami ESX istatistiklerinden incelerken Active Memory istatistiği çok yanıltıcı olabiliyor. Database sunucularının ram erişimi ve cache’lemesi farklı olduğu için Active Memory istatistiği sanal sunucunun gerçekte ihtiyacı olduğu ram’i göstermiyor. Dolayısıyla DB sunucunuz ile ilgili performans analizi yapılacaksa bunu ESX yerine işletim sistemi içerisinden yapmak gerekli. 16 GB ram verilen sanal sunucuda Active Memory 2 GB gösterdiği halde veritabanınıza ram yetmiyor olabilir.

VM Depolama Ayarları
Oluşturulan VirtualDisk’ler Thick Provision Eager Zeroed ile oluşturulmalı. Thin Provision ve Lazy Zeroed’da ilk veri yazılmaya çalışıldığında storage üzerindeki alan talep edildiği için ufak bir yük biniyor. Eager Zeroed ile bu alan en baştan istendiği için bu yük binmiyor.

Sanal makine üzerinde OS, DB, LOG ve Backup Diski olmak üzere minimum 4 virtual disk oluşturulmalı ve bu 4 sanal disk farklı SCSI Controller’lar üzerinde çalışmalı. OS diski LSI Controller üzerinde çalıştırılabilir fakat diğer tüm disklerin Vmware Paravirtual SCSI Adapter üzerinde çalışması gerekiyor.

Paravirtual SCSI Adapter QueueDepth ayarı regedit’ten Windows Server maksimumu  olan 256 olarak ayarlanmalı
“HKLM\SYSTEM\CurrentControlSet\services\pvscsi\Parameters\Device /v DriverParameter /t REG_SZ /d “RequestRingPages=32,MaxQueueDepth=254”.

Depolama alanı olarak Raw Device Mapping ile storage üzerinden oluşturulan alanın direkt olarak sanal makineye map edildiği RDM diskler açıkçası eskisi kadar önerilmiyor. Çünkü bu konuda yapılan IO testlerinde Sequential 4k okuma testi haricinde arada nerdeyse hiçbir fark yok. Sequential 4k Okuma testinde de

RDM: 38.000 IOPS
VMFS: 35.000 IOPS

değeri sağlamış. %8’lik bir kayıp söz konusu. Bu testi 8k, 16k ile yaptıklarında neredeyse hiç fark yok.

Network Ayarları
VMXNET3 ayarı olan Receive Side Scaling etkinleştirilmeli
netsh interface tcp set global rss=enabled
Windows VMXNET adaptör ayarlarından enabled olarak seçilmeli.

Dökümanlarda NSX, VSAN, Virtual Volumes konularında da uygulanması gereken detaylardan bahsedilmiş fakat ben çok göz önünde olan ve kesinlikle heryerde uygulanması gereken net ayarlara dikkat çekmek istedim. Bu detayları uygulamak  her veritabanı sunucusu için kritik.

ReFS Dosya sistemi hakkında kritik bilgi

Merhabalar

Microsoft’un Windows 2016’da iyiden iyiye geliştirdiği dosya sistemi ile ilgili bir problem var ve Microsoft bu konuda bir patch yayınlayabilmiş değil.

ReFS özellikle backup almak için veya dosya sunucusu olarak kullanmak için mükemmel bir dosya sistemi fakat bu volume’ü oluştururken eğer Cluster size’ı 4K seçerseniz Windows 2016 memory hatası ile durduk yere kendini kilitliyor. Bu çözümün etrafından dolaşabilmek için cluster size’ı 64k seçebilirsiniz. 64K’da bu sorun yaşanmıyor fakat bu sefer de dosyalar %10 daha fazla yer kaplıyor. Muhtemel patch’in Mart ayında çıkması bekleniyor ama şuanda bu dosya sistemini kullanmak için mutlaka 64k seçilmeli.

Düzeltildi: https://support.microsoft.com/en-us/help/4016173/fix-heavy-memory-usage-in-refs-on-windows-server-2016-and-windows-10

VMware’den yeni patent başvurusu

Geçtiğimiz günlerde Vmware yeni bir patent başvurusunda bulundu. Muhtemelen ilerleyen sürümlerde VMware ESX’i non-distruptive upgrade yapabileceğiz. Her ne kadar Vmotion ile host’lar üzerindeki yükü kesintisiz taşıyabilme imkanı olsa da özellikle Linux VM’lerde bu taşıma esnasında kesintiler olabiliyor. Özellikle bazı yazılımların lisans kontrolünü yapan USB cihazlar nedeniyle de Vmotion kullanırken kesintiler yaşanabiliyor. Bu açıdan ESX çalışırken upgrade edilebilir olmasının çok işe yarayacağını düşünüyorum.

Vmware Converter Senkronizasyonu

Özellikle büyük boyutlu fiziksel sunucular veya kapatılması güç sunucular için Vmware Converter’daki senkronizasyon seçeneğini kullanmak gerekli.

Böylece saatlerce süren convert işleminin ardından sadece değişen block’lar aktarılarak sunucunun downtime süresi minimumda tutuluyor.

Bu süreçte dikkat edilecek birkaç nokta haricinde normal convert’ten pek bir farkı yok.
11
Öncelikle Advanced Options’dan ilgili seçeneği işaretliyoruz ve Perform final synchronization tickini kaldırıyoruz.

2

Convert işlemi bittikten sonra SQL, Exchange vb gibi servislerimizi durdurup anlık veri girişini engellememiz gerekiyor.

Daha sonrasında  Jobs bölümüne gelip ilgili göreve sağ tıkladıktan sonra Synchronize’e basıyoruz. Convert ekranı tekrar açılıyor fakat bu sefer Advanced Options’daki Perform final syncronization seçeneğini işaretlememiz gerekiyor. Böylece converter son defa sanal makinayı eşitleyip kapanışı gerçekleştiriyor.

Test olarak 400 GB’lık bir Exchange 2010 makinasını sanaldan sanala convert ettim. Convert işlemi kendi içinde olduğu için 1 saat gibi kısa sürede bitti. Normalde 400 GB’lık bi convert 2-3 saat civarı sürer. Herneyse; daha sonra convert’in senkronizasyonunu başlattığımda ise sadece 5 dakika sürdü.

Örneğin artık 2-3 TB’lık sunucuları bile kullanıcı erişimini uzun süre kısıtlamadan convert etmek mümkün.