Inode limit: отново за качеството на хостинг услугите

Ако сте клиент на една от „водещите“ хостинг компании в България, вероятно поне веднъж сте получавали следното загадъчно съобщение:

Чудите ли се какво става? Как е възможно дисковото пространство да е почти непокътнато (12%), но въпреки това да бъде изконсумирано на 80%? Хостинг компанията ви хвърля по върбите, това става…

Най-напред, нека обясня накратко какво представлява inode: това е една структура, която е част от файловата система в Unix-подобните операционни системи и е предназначена да съхранява мета-данни за всеки файл и всяка директория, запаметени на определено устройство. Всеки файл и всяка директория консумират по един inode, и всеки inode номер еднозначно съответства на един файл или директория. (Ако искате да научите повече за inodes, прочетете тази статия в How-To Geek.)

По исторически съображения, повечето файлови системи заделят фиксирано пространство върху диска за съхранението на inodes. Ако пространството, предвидено за съхранение на inodes свърши преди пространството, предвидено за съхранение на файлове, дискът не може да поема повече файлове, въпреки че не е пълен догоре. Така че реални ограничения за количеството inodes съществуват. Но доколко практични са те в една съвременна среда? Нека видим.

Какво количество Inodes е нормално?

Доколкото ми е известно, няма възприето универсално правило за определяне на броя Inodes. Той се задава при създаването на нов дисков дял по време на инсталацията на нова операционна система, като обичайно инсталаторът посочва някакво число, съобразено с вижданията за нормална употреба на проектантите на съответната операционна система. Може и да се зададе ръчно в зависимост от прогнозния начин за използване на този дял.

Нека разгледаме два примера.

На два метра от лявата ми ръка стои един HP Microserver Gen8, който е моята платформа за разработка и тестове. Поради липса от необходимост да съхранява много данни, той е екипиран със доста скромно количество дискова памет: само 480 GB (около 450 GiB). Ето как изглежда потреблението на неговия диск:

❯ df / && df -i /
Filesystem                 1K-blocks     Used Available Use% Mounted on
/dev/mapper/micro--vg-root 457013528 78641132 358652964  18% /
Filesystem                   Inodes  IUsed    IFree IUse% Mounted on
/dev/mapper/micro--vg-root 29032448 728455 28303993    3% /

Както виждате, дискът е запълнен на 18%, но са изразходени само 3% от възможните Inodes. Това разпределение на inodes (1K-blocks/Inodes=16) се е получило, понеже стойностите по подразбиране при създаване на EXT3/EXT4 дялове под Linux са именно такива: 1 inode за всеки 16KB дисково пространство. По всичко личи, че докато спазвам същото поведение при работата с тази машина, ще запълня диска с полезна информация по-бързо, отколкото ще стане невъзможно записването на повече файлове заради изчерпани inodes.

Сървърът, на който се хостват този сайт, трите ми магазина и други сайтове, разполага с 1.5 TB (около 1.25 TiB) дисково пространство. Ето как изглежда дисковото пространство:

❯ df / && df -i /
Filesystem        1K-blocks     Used  Available Use% Mounted on
rpool/ROOT/pve-1 1225225728 27951232 1197274496   3% /
Filesystem           Inodes IUsed      IFree IUse% Mounted on
rpool/ROOT/pve-1 2394645433 96441 2394548992    1% /

Дисковото пространство (изразено в блокове по 1K) е 1,225,196,032. Тоест, при липсата на други ограничения освен размера на секторите, бих могъл да съхраня приблизително 1,2 милиарда файла, всеки от тях с размер ≤1024 байта. Вижда се също, че разполагам с 2,394,645,433 inodes (двойно повече от броя сектори). Тоест, невъзможно е да изразходя inodes, преди да свършат секторите.

Понеже тук операционната система (Debian Proxmox) и файловата система (ZFS) са с различно предназначение, стойностите по подразбиране са различни. Допускам, че заради характерните особености на ZFS съотношението дисково пространство/inodes е подбрано да бъде много малко: 1K-blocks/Inodes=512, т.е. системата може да работи със сектори (клъстери) 512B.

И в двата случая (мога да дам още примери от други машини, но не искам да ставам съвсем скучен…) изборът на Inodes е станало напълно самостоятелно при първоначалната инсталация на операционната система на сървъра; не съм бил питан и не съм изменял съзнателно процеса на създаване на файловата система и дяловете, за да си правя някакви сложни сметки. И въпреки това не се чувствам заплашен от преждевременно изчерпване на Inodes. Значи може 🙂

Правя уговорката, че двете машини, които давам за пример, са (1) различни помежду си — с различна операционна и различна файлова система и (2) със сигурност различни от машините на хостинг доставчика. Но конкретните числа не променят по-нататъшните ми наблюдения и изводи.

Малко или много са 150 GB?

1.5TB се равняват (грубо) на 1500GB. Тоест, дисковото пространство на моя сървър ще бъде ангажирано напълно, ако привлека само 10 клиента на плана, който се рекламира със 150GB дисково пространство. А все пак говорим за сървър с 16 процесорни ядра и 32 нишки, със 128GB RAM памет. Тази машина би могла да обслужва много повече от 10 сайта. Какво да направим, за да можем да оползвотворим по-рационално ресурса на сървъра?

Най-лесното нещо е да обещаем на клиентите си по 150GB дисково пространство, след което да попречим на огромното мнозинство от тях да го използват на практика, като се възползваме от реалностите на уеб хостинга: обичайно интернет сайтовете ползват много на брой, малки по размер файлове (шаблони за страници, php код, графични елементи, скриптове, кеш файлове, помощни файлове със сесии и т.н.). Затова, като си пишем офертата за пред клиенти, казваме: можем да ви дадем да ползвате до 150GB дисково пространство, но ви позволяваме в него да държите не повече от 270 хил. файла във всеки един момент.

Освен ако не съхранявате малко на брой, големи по размер файлове (примерно, видеоклипове), вие никога няма да можете изконсумирате обещаното ви дисково пространство. Ако приемем, че средната големина на файловете във вашия хостинг акаунт е 50KB, то ограничението от 270,000 nodes ще ви позволи да запишете във вашия 150GB-ов хостинг план файлове с общ размер малко над 13GB. А хостинг операторът ще може да наблъска на своя сървър над 100 клиента като вас, вместо само 10. Найс, а?

Последното нещо, което искам да кажа, е адресирано към онези читатели, които биха ме репликирали, че аз не мога да знам каква е инфраструктурата на хостинг оператора, който налага тези ограничения на своите клиенти и може наистина да има някаква причина за тези лимити. За тях копирам по-долу справка за потреблението на дисковото пространство и inodes, извадена през ssh конзолата на същия този потребител, получил притеснителното съобщение, че е достигнал 80% от своята квота дисково пространство:

××××××××@××××××××.bg [~]# df /home/×××××××× && df -i /home/××××××××
Filesystem       1K-blocks       Used  Available Use% Mounted on
/dev/sdf1      12783171488 4779758832 7359151284  40% /home/××××××××
Filesystem        Inodes    IUsed     IFree IUse% Mounted on
/dev/sdf1      402653184 22283997 380369187    6% /home/××××××××

Дисковото пространство на машината (не на потребителския акаунт) е 12TB и е запълнено на 40%. А достъпното количество inodes е 400 милиона и от тях са консумирани само 6%. От съпоставката на двете числа (1K-blocks/Inodes=32K) се вижда, че файловата система борави със размер на сектора (клъстера) 32KB. Което според мен води до разхищение на дисковото пространство: файл с размер 1 байт ще заеме 32KB, а файл с размер 32,769 байта (32K и 1 байт) ще заеме 64KB.

Но както виждате — важното нещо е, че свободни Inodes има, колкото душа иска, и при такъв голям размер на клъстера това е нормално. Тоест, ограничението от 270,000 файла, което ви е наложено, е подчинено само и единствено на търговските съображения на хостинг оператора и няма техническа обосновка.

Добре, и?

Защо пиша тези неща ли? Защото сравнението на оферти в морето от хостинг предложения е трудно. Защото повечето хостинг компании създават умишлено илюзията за избор, като предлагат оферти с напълно произволни, несъобразени с никакви реални ползи за клиентите лимити върху потреблението — и вие като собственик на сайт и мой потенциален клиент трябва да знаете как се прави този кренвирш. И както съм писал и друг път — търсете качеството.

Моделът с фиксираните оферти (евтина/средна/скъпа) е остарял и генерално погрешен, понеже е несправедлив — винаги се получава така, че едни клиенти плащат повече за по-малко потребление, или плащат за услуги, които никога не могат да потребят в пълния им размер, и неадекватен — защото не отговаря на вашите потребности като клиент, а само на разчетите за възвръщаемост на хостинг компанията.

Ако работите с мен, нещата няма да се случват по такъв начин. Смисълът на съвместната ни работа е да оценя вашите конкретни нужди като клиент, и да осигуря необходимите ресурси (дисково пространство; памет; процесорно време) на реалната им стойност. Моето възнаграждение се формира от добавената стойност, която нося за вашия бизнес, а не от препродажбата на имагинерни компютърни ресурси с голяма надценка.