Skrivet av trexake:
Ska kolla vidare på det där med en SSD delad för både system och cache, vad är huvudanledningen till att du rekommenderar att ha en hel disk? Vid hur stor belastning kan man anse att man behöver en SSD cache? Servern utsätts inte för extremt stora påfrestningar.
Med cache i detta fall tänkte jag på både ZIL och L2ARC (inte ZFS cache vilket är samma som L2ARC). För just ZIL och hög belastning kan hela SSDn nyttjas vid skrivningar (och inte bara en del av dem) som i såfall ger fler IOPS. För L2ARC är det ingen större skillnad vad jag har kunnat se eller läsa mig till. I detta fall för ett mindre system är det nog ingen fara skulle jag tro. Så partitionera upp SSDn så bör det nog gå bra (ZVOLs kan också användas om man ej vill partitionera men det innebär ett extra lager som kan hämma framför allt prestanda för ZIL som är mer latensberoende). Notera dock att ZIL endast används vid synkrona skrivningar (som standard görs inte detta via t.ex. Samba).
EDIT:
Såg just att jag missaede en fråga gällande vid vilken belastning man märker av att cache bör användas. Svaret är att det är svårt att säga. Jag körde tidigare torrent på samma pool som hade övrig lagring och märkte att lagringen kunde bli lite stötvis ibland. Efter att ha lagt till ZIL och L2ARC (partitionerade upp en gammal SSD) så blev det bättre. Cache behövs främst när det handlar om många IOPS som t.ex. virtuella maskiner, databaser där alla data ej kan hållas i minnet, många synkrona skrivningar samt ifall lagringen börjar användas av flera användare samtidigt (räcker med skript som kanske körs i backrunden och packeterar/skannar data eller liknande, beroende på vad man har valt att lägga till). Vid användning av endast Samba (utdelning till Windows) så kommer ZIL ej behövas med standardinställningarna. Däremot kan L2ARC hjälpa upp ifall viss data läses ofta och ej får plats i RAM. Nu bör ditt RAM räcka till en del då vi nog ändå bara talar om låg belastning.
Allmän diskussion
Jag är själv i läge att ändra hur min lagring ska te sig hemmavid. I början satsade jag på en "ordentlig" filserver som skulle hantera backuper i en zpool och sedan resten i en annan. Den uppsättningen har ju sina fördelar men även nackdelar:
Alla hårddiskar i samma maskin innebär att alla skulle kunna gå sönder samtidigt av t.ex. elfel.
Med den diskuppsättning jag körde blev det mycket utrymme oanvänt (backup: mirror, annat: raidz). Då backuppoolen bara backupade det viktigaste användes ca 20% av poolen bara.
Då nuvarande chassi endast har plats för 6x 3,5" och 5 platser redan användes fanns det ont om urymme för att bygga ut.
Resultatet har istället blivit att jag kommer satsa på en uppsättning osm påminner om du nuvarande: en allt-i-allo-server och sedan en backup-server. I mitt fall är jag visserligen inte begränsad till 2st N54L utan kör med hemmabyggen (vettigare serverkomponenter i allt-i-allo-servern och sedan gamla komponenter till backupservern). Dock kör jag backuper av hushållets maskiner till allt-i-allo-servern som i sin tur backupar allting till backupservern som kommer vara offline större delen av tiden förutom när backup sker.
Fördelar:
Allt-i-allo-servern har mer prestanda och kommer köra tjänster som primärt används. Backupservern kommer i detta fall vara en gammal Core 2 Duo som just nu bara samlar damm ändå.
Backuper från övriga maskiner (både fysiska och virtuella) kommer ju att köras. Nackdelen här är väl att det blir en del backuper som för tillfället lagras på samma maskin (primärt de virtuella maskinerna). Dock lagras de i olika pooler så visst "skydd" finns ju.
Backupservern kommer vara offline och därmed inte påverkas av t.ex. elfel som kan uppstå när den är urkopplad.
Då all data ska backupas (om än manuellt) så behöver inte samma grad av redundans användas. Enklare redundans kan nyttjas på både primära servern och backupservern. Givetvis är det är ett övervägande jag får göra när jag ska köpa in mer disk.
Nackdelar:
Den mesta datan på allt-i-allo-servern kommer endat backupas när jag gör det manuellt. Finns risk att det kommer bli sällan då den kommer behöva kopplas in och dras igång vid varje tillfälle. Förberedda skript kan underlätta.
Behöver jag stänga av allt-i-allo-servern kommer alla tjänster på den att gå ned. Genom att köra två olika servrar kommer en del fortfarande att köras.
Nu är jag bara i mitten av detta arbete så jag kommer säkert uppotäcka fler för- och nackdelar. För rent labbande har jag valt virtuella maskiner för att göra så liten åverkan som möjligt på servern (kör med virtualbox som fungerar bra förutom vid viss IO). Med lz4-komprimering tar en FreeBSD-maskin ca 700 MB vilket gör valet lätt att lagra dem på SSD.
Då ZFS lätt kan bli fragmenterat med tiden och innebära sämre prestanda har jag valt att köpa in två slaskdiskar på 1TB som jag speglat för sådan data som kommer skrivas och ändras väldigt mycket (tänk en "scratch"-disk). Blir prestandan för dålig i den poolen kör jag backup till den större och helt enkelt bara skapar om den. Skulle jag förlora poolen är det ingen större fara då all viktig data ligger lagrad på en annan pool, alternativt har kopierats över.
Mitt tips är nog att testa dig fram för att se vad som passar dig. Speglar kommer ge bättre prestanda sett till IOPS och endast halva poolen kommer arbeta vid byte av disk. Men högre redundans kan dock vara värt det så man ej behöver stressa så mycket ifall en disk går sönder. Är själv lite kluven hur jag ska göra själv framöver utan har tänkt att jag får testa mig fram med olika konfigurationer. gstat är ett bra hjälpmedel vid prestandagranskning av hårddiskar. Till kryptering misstänker jag att du redan tänkt använda geli?
Oavsett hur du nu gör (om du inte redan hunnit med det) så rekommenderar jag starkt att dokumentera allt du gör. Gärna med kommandon för copy&paste. Jag kör själv med en hostad mediawiki för detta ändamål så jag enkelt kan gå tillbaka alternativt kolla upp hur man löser vissa saker som man väldigt sällan vidrör. Exempelvis har jag lagt in nästan alla kommandon som jag körde senast jag installerade om servern (bytte till SSD för systemdisk) vilket gör att nästa gång jag ska installera om finns det mesta redan inlagt där så det kommer gå snabbare.