Eida.cz - Kapsy pro budoucnost

Tento týden byl přelomový, protože Apple podle očekávání konečně poslal Intel do kytek a naběhl na vlastní čipy, čipy čipy. O Apple Silicon, ze kterého zatím představili prvního zástupce M1, snad ještě budu někdy rozjímat, ale v kostce už o tom napsali ostatní, takže není důvod dokola opakovat zjevnosti. Přesto se v tichosti odehrála ale ještě zlomová událost, a tou je podpora časových kapes ve formě APFS v systému Big Sur.

Big Sur s kapsami!

Problematika pořádného zálohování pomocí Apple Time Machine je u mě poněkud živé téma zhruba od Vánoc 2010, takže to můžeme zaokrouhlit zhruba na deset let trvající proces s poněkud nejasnými výsledky, alespoň co se týče zaručených a univerzálních rad, jak si s případnými starostmi a haváriemi poradit. Když to tak nějak historicky shrnu, tak enterprise podpora — kterou je tedy myšleno zálohování do sítě na opravdové servery a nikoliv na nějaký podřadný externí disk po USB — přišla až někdy se Snow Leopardem a hackem pro dvojkový Netatalk, následovaná nejasným rozjímáním, proč se vlastně záloha může někdy pokazit a pak hlavně taky co dělat, když se opravdu pokazí. Dneska už pevně víme, že se záloha kazí kvůli tomu, že v útrobách Netatalku přeteče čítač, takže je nutné ho pravidelně restartovat, ideálně co týden nějakým skriptem (za předpokladu, že tam není v ten okamžik nikdo připojený a Macy se zálohují automaticky každou hodinu).

Každopádně to poslední, co přetrvalo, je sporadická rychlost zálohování. Z nějakého důvodu ve mě tkví přesvědčení, že při bezdrátovém zálohování je rychlost omezována nějakým mechanismem přímo v macOS, protože při použití kabelu se dá dosáhnout prakticky plného potenciálu, který síť a síťová zařízení nabízejí (na gigabitu velmi reálně blízko 100 MB/s). Při bezdrátovém spojení, které je už dneska prostě všude 802.11ac a dosahuje reálných rychlostí linky okolo 860 Mbit/s, probíhá inkrementální (ale i prvotní) zálohování do maximální hranice 30 MB/s, ale průběrně to bude sotva polovina, spíše takových 12 MB/s. Ale proč?

Kdo ví a tuší, tak přestože všechny systémy jsou už poměrně moderní a žijí v budoucnosti, časové kapsy až dosud používaly ve své interní struktuře case-sensitive HFS+, kde se zřetězení a verzování dat dalo dosáhnout jen pomocí hardlinků. Samozřejmě HFS+ je tu hodně dlouho a v Apple dobře věděli, že s flashovými úložišti přístroje přejdou na novinku, jen s těmi kapsami toho moc nenadělali. Až do teď. APFS je moderní věc kombinující správce svazků a souborový systém; její hlavní předností ve smyslu verzování jsou pochopitelně snapshoty, používá se taky výhradně CoW a totální deduplikace a všechny tyhle mlsky. S příchodem systému Big Sur se objevila docela nevýrazná zprávička, že Time Machine začne APFS taky podporovat, což výrazně zrychlí prováděné zálohy. Nuže, jo?

Je potřeba si před testováním říct ještě něco. Netatalk běží nad starým AFP protokolem — starým ve smyslu verze 3.4 z roku 2012 a éry Horské Kozy — a dělá to víc než dobře. Apple by rád podporu AFP zahodil z mnoha důvodů, ostatně už docela dlouho není možné vytvořit AFP share přímo z Macu, přesto se i Big Sur stále umí napojit a používat vzdálené AFP. Jako náhrada se plánovalo použití sjednoceného SMB, ale to se pořád nějak neosvědčilo. Jenom stručně — implicitní nastavení Samby v Linuxu úplně dobře nebude podporovat všechny ty macovské vychytávky a hlavně, protože nebude použit žádný řadič nebo Kerberos, je uživatelská báze závislá na interní, nikoliv systémové implementaci. Proti tomu Netatalk používá vnitřní uživatele, byla kolem toho ostatně žahavá diskuse s přechodem na OpenSSL 1.1. Za další, protože je všechno dneska Bonjour a Avahi, není úplně snadné používat bok po boku Sambu i Netatalk a hlavně, AFP přenosy v Netatalku mají tak nízkou režii, že Sambu předčí téměř ve všech ohledech. Dnešek teda byl vlastně o dvou testech — jednak zjistit výhody APFS kapsy nad HFS+, ale taky pokusit se v reálném prostředí porovnat provoz SMB a AFP kapes.

Souběh služeb na jednom hostiteli není z uživatelského hlediska úplně přítulný – samozřejmě člověk může pro obyčejné spojení explicitně použít Cmd+K, ale ve chvíli, kdy chce jen tak bezcílně procházet síťové okolí z Finderu přes Bonjour, macOS bude preferovat SMB před AFP. V případě stejného názvu hostitele (to je v rámci síťového multicastu něco jako server.local) se tedy server ukáže pouze pod jednou ikonou, na které zrovna běží Samba. To mi vážně nevyhovuje, protože chci používat AFP na běžné sdílení souborů co to jen půjde, takže to chce menší zásahy do nastavení Samby a Avahi, jelikož oznámení SMB disku je pro bezproblémový (a bezzásahový) chod Time Machine klíčové. Vycházejme z toho, že se linuxové služby (Netatalk a Samba) do Avahi registrují samy. V případě Netatalku není potřeba dělat nic, pro Sambu pak bude nutné upravit konfiguraci následovně – aby podporovala nějakým způsobem AAPL rozšíření, exportovala kapsu, ale hlavně aby se přestala hlásit.

[global]
	# nějaká výchozí globální nastavení
	...

	# vypnutí hlášení Samby v Avahi -- Netatalk bude default
	multicast dns register = no

	# AAPL rozšíření -- ea vypnou podporu wide links, tak pozor na jiné shary
	ea support = yes
	min protocol = SMB2
	vfs objects = acl_xattr fruit catia streams_xattr
	fruit:aapl = yes

	fruit:model = TimeCapsule
	fruit:posix_rename = yes
	fruit:veto_appledouble = no
	fruit:wipe_intentionally_left_blank_rfork = yes
	fruit:delete_empty_adfiles = yes

	# důležité -- přenos defaultně ignoruje vnitřní POSIXové ACL a uvažuje ACE
	# záznamy, takže to může skončit tím, že kapsa nebude mít
	# oprávnění pro zápis
	fruit:nfs_aces = no

	# Netatalk interoperabilita
	fruit:metadata = netatalk
	fruit:resource = file
	fruit:locking = netatalk
    fruit:encoding = native

	# xattr pro streamy
    streams_xattr:prefix = user.
    streams_xattr:store_stream_type = no

    # někdo ještě dělá nastavení na úrovni socketů, ale je potřeba pamatovat,
    # že tohle se odvíjí od dané vrstvy a manuální nastavení bufferů
    # nemusí v nových verzích Samby fungovat lépe, než autotuning
    socket options = IPTOS_LOWDELAY

[TEST SMB Time Machine]
	# obecná nastavení -- jinak není přístup k položce
	path = /server/timemachine/testsmb
	browseable = yes
	read only = no
	valid users = eida @eida

	vfs objects = fruit catia streams_xattr
	# Time Machine
	fruit:time machine = yes
	# limit na 1 TB
	fruit:time machine max size = 1 T
	# přepis globálního nastavení -- používat streamy
	fruit:metadata = stream

	# pak si můžeme hrát s per-share asynchronním přístupem
	aio write size = 16384
	aio read size = 16384

Pak stačí reload/restart smbd a nmbd a hle, Sama server z Finderu konečně zmizel, jupijej. Bohužel to znamená, že nastavení Time Machine ale sdílený prostředek pro kapsu neuvidí a bylo by pak nutné složitě ručně udělat připojení k prostředku a jeho export do TM, nicméně daleko snazší bude exportovat přímo do nastavení Avahi konkrétní služby – následující konfigurace je klasická service definice pro Avahai, typicky automaticky načítaná z /etc/avahi/services/, která se stará o několik věci najednou:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <!-- namísto prostého %h je lepší mít separátní označení -->
  <name replace-wildcards="yes">SMB %h</name>

  <service>
    <type>_adisk._tcp</type>
    <port>0</port>
    <!-- adVF=0x100 - vyžadováno přihlášení k prostředku -->
    <txt-record>sys=waMa=0,adVF=0x100</txt-record>

    <!-- každá kapsa by měla mít vlastní podobný záznam podle dk#=: -->
    <!-- název musí odpovídat jménu prostředku v Sambě;
    0x82 = TM s podporou SMB (0x83 pro SMB i AFP),
    ještě by taky mělo být specifikováno adVU s UUID svazku
    vygenerované třeba z /proc/sys/kernel/random/uuid -->
    <txt-record>dk0=adVN=TEST SMB Time Machine,adVF=0x82,adVU=aa84e14d-8397-4fb7-9a72-4159a355b16f</txt-record>
  </service>

  <!-- obecné označení portu služby - SMB tcp 445 - protože se globálně neinzeruje -->
  <service>
    <type>_smb._tcp</type>
    <port>445</port>
  </service>

  <!-- ikona celého stroje, jak se bude ukazovat ve Finderu -->
  <service>
     <type>_device-info._tcp</type>
     <port>0</port>
     <txt-record>model=TimeCapsule</txt-record>
  </service>

</service-group>

V první řadě se název serveru přepíše na jiný, zde tedy bude prefixovaný SMB, ale je to hlavně kvůli tomu, aby nedošlo k přepisu výchozího Netatalku. Bohužel kvůli celé parádě musíme sdělit, že je to tedy SMB služba na TCP 445, ale zas jako bonus lze vybrat obrázek, resp. mimic model služby, který se zobrazí ve Finderu při procházení sítě – zde to bude ikona Time Capsule. No a pak to hlavní, bohužel nejvíc složité – jako _adisk._tcp bude nutné vyjmenovat všechny sdílené prostředky, co by to mělo automaticky nabízet pro macOS. Doporučuji tohle omezit pouze na časové kapsy (jsou označené adVF=0x82) a ostatní prostředky tady nedefinovat. Ale víšjak, každýmu podle jeho gusta.

Po těchto prvotních přípravách bylo tedy konečně možné přikročit k tomu testování. Vlastně kecám, byl to průběžný proces, ale příprava se vždy hodí. Ve všech případech jsem použil Big Sur 11.0.1 na poněkud netypickém stroji MacBookAir9,1 v reálných pokojových podmínkách – je použita enterprise wifi při 802.11ac s nejnižší zaznamenanou propustností 520 Mbit/s, pokud se System Profileru dá tedy v tomto věřit. To by samo o sobě mělo zaručit přenosy o skutečných rychlostech okolo 60 MB/s, což bylo ostatně ověřeno obyčejným kopírováním souborů přes AFP i SMB tam i zpátky – zde byla wifi skutečně jediným omezujícím faktorem s průměrnou propustností 70 MB/s. Na serveru běžel x86_64 Debian testing/sid s jádrem 5.8.14, Netatalk 3.1.12 a Samba 4.12.5, prostředky byly uloženy na RAID1 poli enterprise disků WD UltraStar s JFS.

Z prvního snímku je možné potvrdit, že nová kapsa se z Big Suru skutečně vytvořila jako APFS, přesto její interní struktura z externího pohledu opět představuje pouze sparsebundle obraz, a tedy žádnou vyloženě zjevnou výhodu proti totožným obrazům s HFS+. Při použití AFP spojení na Netatalk se rychlosti pro prvotní zálohu nijak nezvýšily, při použití SMB docházelo ke značným fluktuacím, kdy sice absolutní čísla chvílemi překračovaly hodnoty 35-40 MB/s, ale celková průměrná rychlost byla proti AFP prakticky poloviční, a to okolo 11 MB/s. Chtělo by se říct, že tohle je možná první varovný signál, že něco nebude v pořádku s výkonem serveru při organizaci jednotlivých souborových bandů v onom sparse-obrazu, ale znovu musím zopakovat, že na kabelu jsou rychlosti nesrovnatelně vyšší, a tedy těžko to bude celé jenom tím. Za zmínku stojí pak taky to, že SMB přenos využíval protokolu SMB3_02 a 25 paralelních spojení, všechny testy se projevily nanejvýš 6% zátěží na straně prostředků serveru.

Po dokončení zálohy proběhlo ještě testování obyčejného kopírování oběma protokoly, přenášela se paralelně data dvou obrazů DVD tam i zpět, rychlosti se oběma směry pohybovaly vysoce nad 60 MB/s a přenos přes AFP byl daleko plynulejší a jejich vybavení bylo proti SMB prakticky instantní.

Zkopírované soubory poté posloužily pro vyzkoušení inkrementální zálohy nad zálohu prvotní, bohužel ani zde se nijak neprojevila výhoda APFS snapshotů a streamových přenosů, rychlosti byly srovnatelně špatné s plnou zálohou, v případě přenosu přes SMB dokonce naprosto tragické, tam se 5 GB rozdílových dat zálohovalo snad 40 minut.

Takže teda nevím, co se to tady jako děje, ale bohužel reálné testy všech pro budoucnost předzpívaných technologií – tedy APFS, SMB a Big Suru – se ukázaly přinejmenším jako velmi nepřesvědčivé. Možná by jistě jen pro případ stálo za úvahu vyzkoušet nějaký nový test na serverovém stroji, který bude pro domácí potřeby víceméně nedosažitelný, zda skutečně není nějaký brouk zakopaný na vzdálené straně, případně pokusit se potunit Sambu jen a jen pro účely TM a ne pro mediální Windows klienty. V tuhle chvíli je možná ještě brzo, protože M1 čipy jsou teprve na cestě, ale vypadá to, že zatím tedy nejsou žádné ultra kapsy pro budoucnost a musíme ještě pár dní vzít za vděk tím, co máme.