Тема дефрагментації файлової системи періодично спливає то на форумі, то просто в пошті.
Так чи потрібна дефрагментація в віртуальному світі, яка як відомо, сильно допомагає в світі фізичному?
На чому з того, що таке фрагментація взагалі і яке її вплив на продуктивність. Отже, фрагментація - ситуація, коли блоки великого файлу розкидані по фізичній диску у випадковому порядку. Вплив фрагментації відмінно видно на звичайній домашній машині з одним жорстким диском і великою кількістю великих файлів (кіно, фото і т.д.). В цьому випадку для читання файлу (наприклад при копіюванні) головка диска не може здійснювати лінійне послідовне читання на максимальній швидкості, а змушена розриватися між блоками. Зрозуміло, все той час, що головка переміщується до потрібного циліндра і чекає початку блоку з даними, читання не відбувається. Підсумок - зниження швидкості читання. Іноді кардинальне зниження, якщо файл виявився розбитий на безліч блоків малого розміру.
Лікування - шляхом послідовних читання / запису перемістити по диску блоки файлу таким чином, щоб в максимальному ступені зробити їх послідовними і соотв. звести перемещанія головки до мінімуму.
Просто, очевидно і веде до легко вимірному перевазі. Але чи так це у віртуальному світі?
А ось тут якраз заритий бегемот.
Давайте уявимо собі середнього розміру інфраструктуру з парою сотень віртуальних машин. Є продуктивний масив з безліччю дисків в RAID, машини генерують навантаження, життя рухається.
Чи впливає якось фрагментація файлових систем всередині ВМ на загальну продуктивність. Парадокс, але практично немає.
1) Оскільки у нас є масив з безлічі дисків, за якими рівномірно розмазані дані, значно знижується вплив переміщення головок - йде практично паралельне читання з декількох дисків, причому практично непередбачувано.
2) Чим більш інтелектуальний дисковий масив, тим менше саме вплив самої повільної частини дискового масиву - дисків. Великий оперативний кеш, кеш другого рівня на флеш-дисках, многоуровненность зберігання знижують вплив дисків аж до того, що до фізичних повільних магнітних дисків доходить іноді всього 10% операцій читання. Потужні процесори, алгоритми оптимізації і великий віддзеркалювати кеш з батарейкою дозволяють не поспішати записувати на диски потік команд як він йде, а робити це оптимальним чином в залежності від рівня і інших параметрів RAID, в мінімальну кількість операцій.
3) Одночасна навантаження з десятків і навіть сотень віртуальних машин привід до того, що тільки всередині ВМ дискові операції виглядають як лінійне читання. До дискового масиву читання / запис доходить вже як практично випадкова послідовність команд. Від того, що файл всередині з однієї ВМ розташований непослідовно, практично нічого не змінюється.
Разом: якщо ВМ розташовані на малоінтеллектуальном масиві початкового рівня (або просто на внутрішньому RAID сервера) на малій кількості фіз. дисків (шпинделів), і їх мало, то дефрагментація може мати сенс і знизити навантаження на дискову систему / підвищити загальну продуктивність.
Однак зі зростанням розмірів інфраструктури та підвищення класу дискової системи фрагментація перестає грати скільки-небудь значущу роль. Зате дефрагментація стає порятунком, а справжнісіньким злом. Згадаймо, що собою представяет процес дефрагментації - безліч операцій читання / запису (1 до 1) в обсязі, що доходить до 100% даних на диску.
А здавалося б, як добре все починалося.
Не всі йогурти однаково корисні.
Буквально позавчора потрапили в подібний халепу. ВМ файл-сервер на пару-трійку сотень гігабайт.Еженочний бекап Net Veritas. Ентузіасти ж поставили також еженочно дефрагменацію із зсувом за часом від бекапа. Незрозуміло чому бекап затримався, збігся з дефрагментацією - і привіт - снепшот виросли практично до розмірів базових дисків, місце на сторадже скінчилося, машина не включається.
Добре, змогли звільнити місце SVmotion'ом пари інших маленьких ВМ зі стораджа. А то б довелося в робочий час вимкнений файл-сервер невідомо скільки клонувати, відповідно downtime найважливішого корпоративного сервера, за що використало б усіх.
Найсмішніше, що дефрагментацію залишили, пересунувши ще за часом. покажу начальству цей пост, може одумаються.
Є сумніви з приводу RAID Penalty
Виходячи з наведених міркувань, raid1 повільніше raid0 на запис в 2 рази, raid5 в 4 і т.д.
Що показують реальні вимірювання?
Так воно все і є :-)
Притому ви забули додати "на одному і тому ж кількості дисків", тому що якщо raid0 на N дисках, то він в N разів швидше дзеркала raid 1 з пари дисків.
Поправлю про CBT. ctk-файл рости не повинен - створюється розміром, залежно від розміру відповідного vmdk.
Але, через дефрагментації відзначатиметься все більше кількість змінених блоків в цій таблиці. А отже прийде бекапер за інфою в наступну свою сесію, і з'ясує, що копіювати йому треба всю машину заново:
1. Час бекапа збільшилася (а при реплікації по WAN це взагалі може стати критично)
2. Розмір инкремента стане рівним повної копії.
3. Плюс затримка при пересобіраніі повної копії з таких інкрементів, або при відновленні.
до речі давно хотів уточнити - cbt записує зміни з останнього снапшотов, так?
тобто якщо після бекапного снапшотов був ще один вручну створений - схема порушується?