NVMe TCP üzerinden dizüstü bilgisayar klonlama

 (copyninja.in)
2 puan yazan GN⁺ 2024-03-13 | 1 yorum | WhatsApp'ta paylaş
  • Yeni dizüstü bilgisayarı sıfırdan yeniden kurmak yerine, mevcut dizüstü bilgisayarın tüm diski NVMe over TCP ile açığa çıkarılarak ağ üzerinden olduğu gibi kopyalandı
  • Mevcut ortamda tam disk şifrelemesi ve 512GB disk kullanılıyordu; yeni dizüstü bilgisayarda ise 1TB NVMe bulunduğundan, kopyalama sonrasında bölüm, LUKS ve BTRFS genişletmesi gerekti
  • Disk dışa aktarma için systemd-storagetm.service yerine iki dizüstü bilgisayar da GRML rescue CD ile başlatıldı ve nvmet-tcp ile /sys/kernel/config/nvmet üzerinden yapılandırıldı
  • Gerçek kopyalama dd ile yapıldı; yeni dizüstü bilgisayarda Ethernet portu olmadığından yalnızca WiFi kullanıldı ve 512GB kopyalama yaklaşık 7 saat 30 dakika sürdü, hız da yaklaşık 18~20MB/s düzeyindeydi
  • Kopyalama sonrasında parted, growpart, cryptsetup resize, BTRFS resize adımlarıyla 1TB'ın tamamını kullanacak şekilde ayarlama yapıldı ve mevcut dizüstü bilgisayar ortamı neredeyse olduğu gibi devralınabildi

NVMe over TCP ile mevcut diski dışa aktarma

  • Yeni dizüstü bilgisayar kurulum sürecini tekrar etmemek için, bir iş arkadaşının önerisiyle mevcut dizüstü bilgisayarın tüm diskini kopyalama yöntemi seçildi

  • Başlamadan önce iki engel vardı

    • Mevcut dizüstü bilgisayarı açıp yeni diski USB ile bağlayacak araç yoktu
    • Mevcut dizüstü bilgisayarda tam disk şifrelemesi ve 512GB disk vardı; yeni dizüstü bilgisayarda ise 1TB NVMe bulunduğundan LUKS boyut ayarı gerekiyordu

  • İş akışı disk açığa çıkarma, kopyalama ve kapasite genişletme olmak üzere üç aşamadan oluşuyordu

    • Mevcut dizüstü bilgisayarda nvmet-tcp ile disk dışa aktarıldı
    • Yeni dizüstü bilgisayarda bu disk kopyalandı
    • Bölüm 1TB'ın tamamına genişletildi
    • LUKS boyutu ayarlandı
    • Son olarak BTRFS kök diskin boyutu ayarlandı

  • systemd-storagetm.service yerine GRML kullanımı

    • En kolay yöntem olarak systemd-storagetm.service kullanılabilirdi
    • rd.systemd.unit=storage-target-mode.target belirtilerek storage-target-mode.target ile önyükleme yapıldığında çağrılabiliyordu
    • Ancak bu yöntem, dracut initrd imajına ağ servislerinin eklenmesini gerektiriyordu ve bu modda WiFi yapılandırması zahmetli olduğundan tercih edilmedi
    • Bunun yerine iki dizüstü bilgisayar da GRML rescue CD ile başlatıldı; ardından mevcut dizüstü bilgisayarda Linux nvmet-tcp modülüyle NVMe disk dışa aktarıldı
    modprobe nvmet-tcp
cd /sys/kernel/config/nvmet
mkdir ports/0
cd ports/0
echo "ipv4" > addr_adrfam
echo 0.0.0.0 > addr_traaddr
echo 4420 > addr_trsvcid
echo tcp > addr_trtype
cd /sys/kernel/config/nvmet/subsystems
mkdir testnqn
echo 1 >testnqn/allow_any_host
mkdir testnqn/namespaces/1
cd testnqn


# replace the device name with the disk you want to export
echo "/dev/nvme0n1" > namespaces/1/device_path
echo 1 > namespaces/1/enable
ln -s "../../subsystems/testnqn" /sys/kernel/config/nvmet/ports/0/subsystems/testnqn
    • Bu yapılandırmayla hedef cihaz NVMe over TCP olarak açığa çıkarıldı
    • Yeni dizüstü bilgisayarda dışa aktarılan cihaz keşfedilip bağlandı
    nvme discover -t tcp -a <ip> -s 4420
nvme connectl-all -t tcp -a <> -s 4420
    • Sonrasında nvme list ile yeni dizüstü bilgisayara bağlanan cihaz doğrulanıp disk kopyalama işlemi yapılabildi

Disk kopyalama ve boyut ayarlama

  • dd ile 512GB kopyalama

    • Kök disk kopyalama işlemi dd komutuyla yapıldı
    • Yeni dizüstü bilgisayarda Ethernet portu olmadığından yalnızca WiFi kullanıldı ve 512GB'ın tamamının kopyalanması yaklaşık 7 saat 30 dakika sürdü
    • Aktarım hızı yaklaşık 18~20MB/s düzeyindeydi
    • Diğer seçenekler arasında önce bölüm ve dosya sistemi oluşturup kök diski rsync ile kopyalamak ya da BTRFS'nin kendi dosya sistemi aktarımını kullanmak da vardı
    dd if=/dev/nvme2n1 of=/dev/nvme0n1 status=progress bs=40M

  • Bölüm, LUKS ve BTRFS genişletme

    • parted, bölüm tablosunun disk boyutuyla uyuşmadığını algıladı ve düzeltme onayı alındıktan sonra bunu otomatik olarak düzeltti
    • İkinci bölümü genişletmek için cloud-guest-utils kuruldu ve growpart kullanıldı
    growpart /dev/nvem0n1 p2
    • Sonraki adımda cryptsetup ile LUKS kapsayıcısının boyutu büyütüldü
    cryptsetup luksOpen /dev/nvme0n1p2 ENC
cryptsetup resize ENC
    • Diske yeniden önyükleme yapıldıktan sonra her şeyin düzgün çalıştığı doğrulandı ve oturum açıldıktan sonra BTRFS dosya sistemi boyutu ayarlandı
    • BTRFS, boyut değiştirmek için sistemin bağlı durumda olmasını gerektirdiğinden live boot durumunda bu işlem yapılamadı
    btfs fielsystem resize max /
    • Sonuç olarak yeni dizüstü bilgisayarda da mevcut dizüstü bilgisayarı kullanmaya devam ediyormuş gibi bir ortam elde edildi
    • Normalde yeni bir dizüstü bilgisayara tamamen alışmak yaklaşık 1~2 hafta sürse de bu yöntemle bu süre azaltıldı
    • Ek olarak NVMe over TCP ile disk dışa aktarma yönteminin öğrenilmiş olması da ayrı bir kazanım oldu

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-13
Hacker News yorumları

  • Yazarın senaryosunda sonuçta dd(1) ile yalnızca seri blok kopyalama yapıldığı için NVMe/TCP kullanmanın pek bir avantajı yok. Karmaşık komutlar basit bir netcat ile değiştirilebilir
    Hedef dizüstü: $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M
    Kaynak dizüstü: $ nc x.x.x.x 1234
    Hedef taraftaki dd, yazmaları tamponlayarak daha hızlı ve verimli hâle getirmek için. Kaynak/hedefe gzip/gunzip eklerseniz, disk dolu değilse ve çok sayıda 0 bloğu varsa çok daha hızlanır. Şahsen ağ üzerinden PC imajı alırken en sevdiğim yöntem ve bunu birçok kez yaptım
    GigE'de sık sık darboğaz sıkıştırma olduğundan gzip için --fast geçirmek iyi olur; daha iyisi, gzip/gunzip yerine lz4/unlz4 kullanırsanız daha hızlıdır. Eskiden 1TB NVMe'li yeni bir Windows dizüstünün imajını GigE üzerinden aldığımda yaklaşık 20 dakika sürmüştü; boş alan neredeyse 0'a yakın sıkıştırıldığı için ortaya çıkan imaj 20GB idi. Genelde o lz4 imajını yedekleyip birkaç yıl sonra dizüstünü bağışlarken unlz4 | dd ile geri yüklüyorum; çok pratik oluyor
    Ancak Linux çekirdek modülü nvme-tcpden haberim yoktu; insan her gün yeni bir şey öğreniyor. Bu, dd ile ham erişim için olmaktan çok, uzak NVMe üzerinde dosya sistemi bağlamakta daha kullanışlı görünüyor
    Ek olarak Linux'ta maksimum pipe tamponu boyutu 64kB olduğundan dd bs=X argümanının teknik olarak bundan büyük olmasına gerek yok. Yine de bs=1M zararlı değil; 64kB okumaları 1MB olana kadar toplar ve ileride pipe boyutu büyürse buna da hazırlıklı olur. Bazı netcat sürümlerinde giriş/çıkış blok boyutu seçenekleri var, bu yüzden dd bs=X gerekmez; ama kurtarma disklerindeki netcat genelde bu seçeneklere sahip olmayan sürümdür

    • Linux'un pipe tamponu büyütülebilir ve varsayılan maksimum değerin genelde 1MB civarında olduğunu biliyorum. Komut satırından yapmak biraz uğraştırıcı ama mümkün bir uygulama örneği https://unix.stackexchange.com/a/328364 adresinde var
    • Biraz dağınık olsa da iki tarafta da dd yerine pv kullanırsanız uygun blok boyutunu belirtme derdi olmaz ve ilerleme grafiği de güzel görünür
    • Yaklaşık 9 yıl önce içeriden hacklenmiş bir şirkete danışman olarak gitmiştim; hoşnutsuz bir kurucu ortak, dead man's switch gibi tüm disklerin ilk 20MB'ını bir bucket'a kopyalatıp sonra sıfırlarla üzerine yazdırmıştı. Verileri kurtarmak için testdisk ile bölüm tablosunu yeniden oluşturmamız gerekiyordu ama ondan önce hasarlı disklere dokunmak istemediğimiz için bir kurtarma flash diski, netcat ve disklerle yaklaşık 40TB kopyaladık
      Bazı sunucularda fiziksel RAID yuvalarının hepsi doluydu, bu yüzden yedek disk yuvası da kullanamıyorduk; kabaca dd if=/dev/sdc bs=xxx | gzip | nc -l -p 8888 ve karşı tarafta bunun ters yönlü komutunu kullandık. Şaşırtıcı derecede iyi çalıştı. Dikkat edilmesi gereken bir nokta, dd bs kombinasyonunu sektör boyutuna göre denemekti; uygun boyut dd aktarım hızını ciddi etkiliyordu
    • Bu dd kullanımı bozulmaya yol açabilir. Blokların kesilmemesi için iflag=fullblock gerekir; körü körüne bir alışkanlık olma riski olsa da conv=sync de zararlı değildir. Şahsen sadece nc -l -p 1234 > /dev/nvme0nX kullanmayı tercih ederim
    • Çoğu kişinin yerel ağı muhtemelen SSD aktarım hızından daha hızlı değildir. Yine de böyle ortamlara sahip olanlar için eşzamanlı giriş/çıkış blok aygıtı klonlama aracı var mı merak ediyorum
      Pipeline'a pv eklerseniz tahmini bitiş zamanını görebilirsiniz, ama performansı biraz etkileyebilir

  • AWS/Annapurna/Nitro/Lightbits'e Linux'a NVMe-over-TCP getirdikleri için teşekkürler
    https://www.techtarget.com/searchstorage/news/252459311/Ligh...
    “NVM Express konsorsiyumu, Kasım 2018'de NVMe/TCP'yi bağlayıcı taşıma katmanı olarak onayladı. Bu standart, başlangıçta Lightbits mühendislik ekibinin NVM Express'e sunduğu kod tabanından gelişti.”
    https://www.lightbitslabs.com/blog/linux-distributions-nvme-...
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Şuna kıyasla çok daha zahmetli görünüyor: nbdkit file /dev/nvme0n1, nbdcopy nbd://otherlaptop localfile

    • Bu yöntem aslında çok daha iyi; çünkü nbdcopy sparse dosyaları işleyebilir, bağlantı ve thread sayılarını çekirdek sayısına göre ayarlayabilir, çıkmadan önce zorunlu flush yapabilir ve ilerleme çubuğunu da açabilir. Şifrelenmemiş bir sürücüyse TLS'yi de destekler

  • Yakın zamanda yeni bir dizüstüne xubuntu kurmam gerekti. Eskiden klonlardım ama bu kez bazı ayarları baştan düzenlemek istedim.
    USB-C kablosuyla 10Gb/s aktarım yapabilmek gerçekten işe yaradı. Çünkü diğer tek seçenek WiFi idi.
    Bilgisayarları birbirine takınca geçici bir ağ oluşuyor ve dosyaları sadece rsync ile geçirmek yeterli oluyor. Görünüşe göre bağlantı doyguna ulaşıyordu, bu yüzden başka bir protokol kullanmanın pek anlamı yok gibi geldi. Elbette yeni bir şey öğrenmek güzeldir ama belki de dizüstü klonladığınız anda değil.

    • Doğrudan çalışıp çalışmadığını merak ediyorum. Ethernet olmayan doğrudan bağlantıyı en son 90'larda denediğim için ciddi ciddi soruyorum.
    • Ben de denedim ama ağın çalışması için 30 doların üzerinde bir Thunderbolt 4 kablosu almam gerekti. Sıradan bir USB3-C kablosu yeterli olmadı.
      Aktarımın kendisi inanılmaz hızlıydı; birkaç dakika içinde 1TB taşıdım. Bu kez şifreleme kullanmadığım için çok daha basitti.
    • Canlı diskten önyükleyip tüm dosya sistemini mi taşıdığını, yoksa temel sistemi kurduktan sonra sadece dosyaları mı taşıdığını merak ediyorum.

  • Neden btrfs'yi ağ üzerinden pipe etmediğini anlamıyorum. Önce bir btrfs snapshot'ı oluşturup btrfs send => nc => network => nc => btrfs receive yaparsanız yalnızca kullanılan bloklar aktarılır.

    • btrfs kullandığını görür görmez benim de aklıma ilk bu geldi. btrfs send/receive'i SSH üzerinden sürekli kullanıyorum ve çok iyi çalışıyor. GRML canlı oturumunda SSH sunucusunu kolayca ayağa kaldırmak da mümkün olurdu.
      Yalnız bir dikkat noktası var. btrfs'de snapshot'ları özyinelemeli göndermek mümkün değil; çok sayıda özyinelemeli snapshot varsa aynı yapıyı yeni diske yansıtmak görece zorlaşıyor. Docker/LXD/Incus'ta bu yaşanabilir. btrfs'yi seviyorum ama özyinelemeli send/receive konusunda ZFS daha iyi.

  • Yakın zamanda WiFi üzerinden yaklaşık 200GB dosya kopyalamam gerekti. Bağlantı koparsa baştan başlamamak ve kayıp olmaması için rsync kullandım ama en az 6 saat sürdü. Daha iyi bir yöntem var mıydı merak ediyorum.
    Ayrıca dd yönteminin ne tür garantiler verdiğini de merak ediyorum. Sonuçtaki blok aygıtının md5'ini karşılaştırmak mı gerekir?

    • 200GB'ı WiFi ile taşımak için 6 saat, yerel aktarım açısından etkileyici bir verim değil. Ethernet kablosu kullanmalıydın gibi görünüyor.
      WiFi'de performans darboğazı yaratabilecek çok daha fazla neden var. Cihazlardan sadece birini bile kabloyla yönlendiriciye bağlayıp diğerini kablosuz bırakmak bile epey yardımcı olur.
    • Dosyalar çok sayıda ve küçükse, rsync'in tek seferde yalnızca bir dosya aktarması büyük olasılıkla darboğaz olmuş olabilir. xargs/parallel ile dosya listesini bölüp birden çok rsync örneği çalıştırabilir ya da kendi içinde paralel aktarım destekleyen rclone gibi bir şey kullanabilirsin.
    • 6 saat kabaca 10MB/s demek; çok daha hızlı yapılabilmiş olması muhtemel. -z ile sıkıştırma yapıp yapmadığını merak ediyorum. Ethernet kullanılabilseydi çoğu cihazda 100MB/s'ye yaklaşır ve yaklaşık 35 dakika sürerdi.
    • rsync'in aktarım yöntemi SSH ise darboğaz çoğu zaman o olur. OpenSSH'nin tarihsel olarak tuhaf performans sınırlamaları vardı ve bunları aşmak için az bilinen yamaların gerektiği zamanlar oldu. CPU darboğaz olmuyorsa sıkıştırmayı açmak da yardımcı olur.
    • WiFi, hava ortamını diğer tüm kablosuz cihazlarla paylaşır. Çakışma algıladığında durur ve rastgele bir süre bekler.
      “Bilgisayar ağlarında çakışma önlemeli taşıyıcı algılamalı çoklu erişim (CSMA/CA), taşıyıcı algılamayı kullanan ancak kanalı yalnızca ‘boşta’ olarak algıladıktan sonra iletime başlayarak çakışmaları önlemeye çalışan bir ağ çoklu erişim yöntemidir. İletim sırasında düğüm paket verisini bütünüyle gönderir.
      Bu, kablosuz vericinin paket iletimi sırasında alıcıyı duyarsızlaştırıp devre dışı bırakması nedeniyle çakışma algılamalı CSMA/CD'nin kullanılamadığı kablosuz ağlarda özellikle önemlidir.
      CSMA/CA, gizli düğüm problemi nedeniyle düşük güvenilirliğe sahiptir.
      CSMA/CA, veri bağlantı katmanında çalışan bir protokoldür.”
      https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_...

  • Bu yaklaşımın avantajları vardır ama eskiden dizüstü taşırken iki tarafta da kurulum programını açıp dd ile nc'yi birleştirirdim. Hatırladığım kadarıyla büyük null alanlarını daha hızlı aktarmak için gzip de eklemiştim.
    Yeni dizüstünde Ethernet portu yoksa, benim hack'li yöntemim sıkıştırma sayesinde biraz daha hızlı olabilirdi. Çünkü ağ hızı, hızlı bir bağlantıda sıkıştırmanın getireceği sınıra yaklaşamayacak kadar düşük olurdu.

    • Tam disk şifrelemesi varsa, LUKS'a TRIM geçişine izin vermesini söylemediğiniz sürece yazarın anlattığı yöntemle aslında yalnızca rastgele veri elde edersiniz.

  • Sadece Clonezilla kullanmak yeterli değil mi? Yalnızca gerçek veri bloklarını kopyalar ve bölümleri otomatik yeniden boyutlandırabilir. Ben hep öyle yapıyorum.
    Tabii genelde dizüstünden NVMe diski çıkarıp yüksek hızlı bir dock'a takıyorum.

    • Clonezilla harika. Tek bir işi var ve genelde ilk denemede başarılı oluyor. Tek şikâyetim, başlangıçtaki öğrenme eğrisi nedeniyle biraz kurcalamak gerekmesi.
      Henüz tamamen güvenip kendi hâline bırakılacak düzeyde değil. Yedekleme, yedekleme artı geri yükleme ile aynı şey değildir; bu yüzden deneme yapmak önerilir. Clonezilla da kaynak diskten çok farklı bir diskte bölümleri yeniden oluştururken sorun çıkarabilir.

  • Masaüstü ya da dizüstüne işletim sistemini gerçekten “kurmayalı” onlarca yıl oldu; hep dosyaları kopyalayıp yalnızca gereken yerleri ayarladım. Genelde bu fırsatı dosya sistemi türü veya blok boyutu gibi parametreleri, şifrelemeyi vb. güncellemek için yeni bir dosya sistemi oluşturup dosyaları rsync ile taşımak üzere kullanırım.
    Yine de önceden plan yapan biriyseniz, yalnızca ayarları kopyalayıp geri kalanını otomatik yeniden kuran NixOS gibi daha bildirime dayalı bir yaklaşım daha iyi olabilir.

  • Cihazları arada AP olmadan WiFi ile doğrudan bağlamak aktarım hızını iki katına çıkarabilir. Bu durumda denemeye değer gibiymiş.