Era quotas

[jbergstroem]

Hej,
har en fråga gällande hur ni satt era quotas. Jag tycker först och främst att förhållandet är ojämnt (ni snålar på antal inodes) och skalar inte linjärt. Detta är bekymrande då ni prissätter efter storlek i bytes. Det är även missvisande när ni också redovisar bytes i statistik och på sätt kan vilseleda de som får problem med sin image (quota exceeded) utan att förstå varför eftersom mätaren i cloud admin redovisar gott om ledigt utrymme.


Jag har här fyra olika images på glesys jag jämför med fyra andra datorer. Alla relativt "bare bone" dock gentoo (portage-trädet har en del filer, dock minskat från ~500mb -> ~200mb)
(df -ih, df -h, sammanslaget för läsbarhet)

image#1 10G:

Kod: Markera allt

Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs             10G  2.1G  8.0G  21% /
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs              293K    216K     78K   74% /


image#2 20G:

Kod: Markera allt

Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs             20G  3.4G   17G  17% /
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs              528K    289K    239K   55% /


image#3 30G:

Kod: Markera allt

Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs             30G  6.5G   24G  22% /
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/simfs              792K    381K    412K   49% /


image#4 150G:

Kod: Markera allt

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/simfs           157286400   3478608 153807792   3% /
Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs            150G  3.4G  147G   3% /


Om jag nu jämför med ett antal system jag kör lokalt:

MBPv3 OS X 160G (HFS+):

Kod: Markera allt

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/disk0s2             35M     28M    7.2M   80% /
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/disk0s2             35M     28M    7.2M   80% /


14G KVM (ext3, 4k bsize)

Kod: Markera allt

Filesystem            Size  Used Avail Use% Mounted on
/dev/vda3              14G   12G  1.9G  86% /
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/vda3             920272  807892  112380   88% /


128G SATA (ext3, 4k bsize)

Kod: Markera allt

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda4             128G  200M  121G   1% /var/tmp/portage
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda4                17M      38     17M    1% /var/tmp/portage


2,3T raid10 sas*14 (xfs, isize=256,sectsz=512, bsize=4096)

Kod: Markera allt

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda4             2.2T  715G  1.5T  33% /storage/d1
/dev/sdb1             2.2T  771G  1.5T  35% /storage/d2
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda4               446M     34M    412M    8% /storage/d1
/dev/sdb1               448M     32M    416M    7% /storage/d2


Om vi då summerar ovanstående så får vi något i stil med:

Kod: Markera allt

name     | size       | inodes    | quota
=====================================================
glesys#1 | 10485760   | 300000    | 0.029 i/b
-----------------------------------------------------
glesys#2 | 20971520   | 540000    | 0.026 i/b
-----------------------------------------------------
glesys#3 | 31457280   | 810000    | 0.026 i/b
-----------------------------------------------------
glesys#4 | 157286400  | 4050000   | 0.026 i/b
-----------------------------------------------------
mbp      | 143707992  | 35926996  | 0.249 i/b
-----------------------------------------------------
kvm      | 14484488   | 920272    | 0.064 i/b
-----------------------------------------------------
sata     | 133562404  | 16973824  | 0.127 i/b
-----------------------------------------------------
raid10   | 2342562200 | 468741312 | 0.200 i/b


Vilka slutsatser kan vi då dra av detta? Glesys är relativt konsekventa när det gäller inode/size förhållandet bortsett från den lägsta diskstorleken där man "snålar" på inodes. Om vi jämför med annan hårdvara ser vi att förhållandet är mellan 3-8 gånger mindre vilket är en ganska stor differens. Eftersom både XFS och HFS+ skiljer sig markant från ext3 så är de ur vissa aspekter "missvisande", men visar ändå på olika alternativ när man har större kontroll över mjukvaru-stacken. Jämför vi en "stock" sata/ext3 setup så är det en magnitud av drygt 5 - vilket jag tycker är kärnan av problemet.


edit1: ändrade ordning på images

[Jonas]

Först skriver du att vi inte skalar linjärt, men sist så skriver du att vi är konsekventa förutom på minsta paketet.
Hur ska du ha det?

Jag har läst igenom ditt inlägg, men ser inte din fråga. Det är riktigt att vi skalar linjärt i vår molntjänst. Är din jämförelse mellan cloud-vps:er eller vanliga vps:eller en blandning?
Att du inte tycker förhållandet med diskutrymmet/inodes är bra för din smak var tråkigt att höra. Hur vill du ha det istället?

Anledning till att vi har en gräns på inoder är att det kostar oss väldigt mkt prestanda när vi tar backuper, flyttar servrar mellan hårdvarunoder m.m.
För de allra flesta funkar det bra. Men har man riktigt mycket filer så fungerar det sämre. Men disk är billigt i vår tjänst, då är det bara att uppgradera lite.

Det kommer alltid vara en differens mellan inoder och utrymme. Vi kan inte skapa en tjänst som passar alla kunder helt 100%, ibland får man köpa mer än vad man behöver. Det gäller även minne, cpu och bandbredd.

Gentoo är kännt för att sluka mycket inoder pga av portage. Jag tror det kan bli lite svårt att få det att fungera på 5GB.

[jbergstroem]

Först skriver du att vi inte skalar linjärt, men sist så skriver du att vi är konsekventa förutom på minsta paketet.
Hur ska du ha det?

Hade ni skalat linjärt så hade första paketet också haft samma block/inode-förhållande, vilket det inte har.

Jag har läst igenom ditt inlägg, men ser inte din fråga. Det är riktigt att vi skalar linjärt i vår molntjänst. Är din jämförelse mellan cloud-vps:er eller vanliga vps:eller en blandning?
Att du inte tycker förhållandet med diskutrymmet/inodes är bra för din smak var tråkigt att höra. Hur vill du ha det istället?

Anledning till att vi har en gräns på inoder är att det kostar oss väldigt mkt prestanda när vi tar backuper, flyttar servrar mellan hårdvarunoder m.m.
För de allra flesta funkar det bra. Men har man riktigt mycket filer så fungerar det sämre. Men disk är billigt i vår tjänst, då är det bara att uppgradera lite.

Det kommer alltid vara en differens mellan inoder och utrymme. Vi kan inte skapa en tjänst som passar alla kunder helt 100%, ibland får man köpa mer än vad man behöver. Det gäller även minne, cpu och bandbredd.

Jag klagar inte på pris eller nivåer i allmänhet, jag tycker ni är extremt konkurrenskraftiga. Det jag hade åsikter om var förhållandet mellan quotan på inodes/hårddiskutrymme vilket jag tycker är i obalans. I kombination med att ni endast redovisar fritt utrymme i bytes kan det alltså uppstå missförstånd kring varför disken är full gränssnittet "bara visar 60% utnyttjande".

Vi kan använda ett fullskaligt portage-träd som exempel:
* Om vi använder en 10G image i er cloud-vps så kommer trädet konsumera ~4,5% diskutrymme och ~36.6% inodes
* Använder vi SATA-exemplet ovan (vilket jag ser som en ganska standardinstall) använder vi i stället ~0,4% diskutrymme och ~0,6% inodes

Gentoo är kännt för att sluka mycket inoder pga av portage. Jag tror det kan bli lite svårt att få det att fungera på 5GB.

Ja, det var därför jag var noga med att notera detta i min jämförelse. Denna jämförelse är dock konsekvent över alla de miljöer jag redovisade (även OS X), samt att jag medvetet hållt storleken på trädet nere till mindre än hälften (visar gärna min --rsync-excludes om så önskas).

Än en gång, är inte ute efter att optimera allt till förbannelse, utan har synpunkter på förhållandet jag nämnde i ovan paragraf.

Tack,
Johan

edit: la till exempel på inode-förhållande mellan SATA och image#1

[Jonas]

Först skriver du att vi inte skalar linjärt, men sist så skriver du att vi är konsekventa förutom på minsta paketet.
Hur ska du ha det?

Hade ni skalat linjärt så hade första paketet också haft samma block/inode-förhållande, vilket det inte har.

Vi satte är minimigräns på 300K inoder. Därför har det minska paketet lite mer. Annars ska det vara linjärt.

Jag har läst igenom ditt inlägg, men ser inte din fråga. Det är riktigt att vi skalar linjärt i vår molntjänst. Är din jämförelse mellan cloud-vps:er eller vanliga vps:eller en blandning?
Att du inte tycker förhållandet med diskutrymmet/inodes är bra för din smak var tråkigt att höra. Hur vill du ha det istället?

Anledning till att vi har en gräns på inoder är att det kostar oss väldigt mkt prestanda när vi tar backuper, flyttar servrar mellan hårdvarunoder m.m.
För de allra flesta funkar det bra. Men har man riktigt mycket filer så fungerar det sämre. Men disk är billigt i vår tjänst, då är det bara att uppgradera lite.

Det kommer alltid vara en differens mellan inoder och utrymme. Vi kan inte skapa en tjänst som passar alla kunder helt 100%, ibland får man köpa mer än vad man behöver. Det gäller även minne, cpu och bandbredd.

Jag klagar inte på pris eller nivåer i allmänhet, jag tycker ni är extremt konkurrenskraftiga. Det jag hade åsikter om var förhållandet mellan quotan på inodes/hårddiskutrymme vilket jag tycker är i obalans. I kombination med att ni endast redovisar fritt utrymme i bytes kan det alltså uppstå missförstånd kring varför disken är full gränssnittet "bara visar 60% utnyttjande".

Det är fler parametrar än inoder som vi inte visar i vår kontrollpanel. Det skulle bli svårt att visa alla parametrar.
Men det är enkelt att se med df-kommandot, precis lika enkelt som att se utrymmet.

Vi kan använda ett fullskaligt portage-träd som exempel:
* Om vi använder en 10G image i er cloud-vps så kommer trädet konsumera ~4,5% diskutrymme och ~36.6% inodes
* Använder vi SATA-exemplet ovan (vilket jag ser som en ganska standardinstall) använder vi i stället ~0,4% diskutrymme och ~0,6% inodes

Jag kan hålla med om att det är snett att defaultinstall visar den faktorn. Dina uppgifter är baserat på Gentoo antar jag.
Samma problem uppstår på andra distrubitioner med extrema krav på inoder. Ex en mailserver med extremt mycket mail och som lagrar i maildir.

Gentoo är kännt för att sluka mycket inoder pga av portage. Jag tror det kan bli lite svårt att få det att fungera på 5GB.

Ja, det var därför jag var noga med att notera detta i min jämförelse. Denna jämförelse är dock konsekvent över alla de miljöer jag redovisade (även OS X), samt att jag medvetet hållt storleken på trädet nere till mindre än hälften (visar gärna min --rsync-excludes om så önskas).

Än en gång, är inte ute efter att optimera allt till förbannelse, utan har synpunkter på förhållandet jag nämnde i ovan paragraf.

Anledning till att vi begränsar inoder är att det kostar mycket IO med mycket filer. Det är mycket dyrare för oss att få bra IO än utrymme. Skulle vi satsa på utrymme skulel vi bara köpa 2TB SATA-diskar, de kostar inget alls.

Vi försöker ha snabba servrar för våra kunder. Det är aldrig CPU eller minne som begränsar våra servrar (i princip).
Det är alltid disk-IO. För att få snabb disk-io så måse vi bland annat sätta begräsning på inoder. Vi tycker att vi har hittat en bra balans mellan snabba diskar och inoder. Denna anses för liten såklart av del kunder som behöver mycket inoder.
Men det passar de allra flesta av våra kunder. Om du vill kan vi ge dig andra lösningar om detta inte funkar för dig.

Som du ser på http://glesys.se/nyheter/nyheter.php?newsid=72 så används Gentoo av bara 5% av våra kunder (den siffran sjunker). Vi har dock andra kunder som behöver mycker inoder, ex maildir-installationer. Om de inte klarar sig så försöker vi förklara varför vi har en gräns och ber dem uppdatera. Och hjälper inte det för att de har ännu större krav så rekommenderar vi antingen en dedikerad server, eller en annan form av virtualisering (där ex inte backup ingår).

Allt handlar alltså om pengar och vad kunder är villiga att betala och vad våra konkurenter gör. Vi kan självklart bara höja inoder med 500%. Men då måste vi antingen ta ut ett högre pris (eftersom vi måste ha mer hårdvara) eller får kunden en sämre tjänst eftersom det blir långsammare.