<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapfrom="Software Architecture" />
  </query-continue>
  <query>
    <pages>
      <page pageid="24" ns="0" title="Rescueing storage">
        <revisions>
          <rev xml:space="preserve">Одна з найбільш прикрих подій за весь час роботи обчислювального кластеру сталася '''12 листопада 2009 року'''. Апаратний вихід з ладу жорстких дисків в RAID-масиві в більшій кількості аніж така можливість передбачена через зношування від інтенсивного використання вже впродовж 3-х років призвів до втрати даних, в тому числі в таблицях файлової системи.

Після перезавантаження елементу збереження під час апгрейду пам'яті файлова система (ext3) розділу, що містив домашні каталоги користувачів, не підмонтувалася. 

 EXT3-fs: group descriptors corrupted!
 EXT3-fs error (device dm-1): ext3_check_descriptors: Inode table for group 8132 not in group (block 0)!

Фалова система знаходилась в стані &lt;tt&gt;not clean with errors&lt;/tt&gt;. В таких випадках є необхідність запустити &lt;tt&gt;fsck&lt;/tt&gt; для виправлення помилок, що і було зроблено '''12 листопада 2009'''.

Розмір розділу, що виділено під домашні каталоги - 3ТБ, і всі процеси описані нижче займають багато часу. Ввечері '''13 листопада 2009''' перевірка завершилась невдало, через пошкоджений суперблок. Запущено &lt;tt&gt;fsck -b&lt;/tt&gt; з використанням альтернативного суперблоку.

'''14 листопада 2009''' перевірка з альтернативним суперблоком завершилася невдало, тому постала необхідність у застосуванні більш радикальних методів. Перед спробами відновити дані ризикованими способами необхідно було зробити повний бекап цього розділу елемента збереження. Але головна проблема - &quot;як?&quot;. Нажаль в нас немає апаратних засобів, на яких було б 3ТБ місця для здійснення бекапу. Було приянято рішення робити бекап по частинам, використовуючи &lt;tt&gt;dd skip&lt;/tt&gt; та &lt;tt&gt;dd seek&lt;/tt&gt; в разі відновлення з бекапу. Для збереження даних використовувалось вільне місце на інший розділах RAID-масиву, знять один диск з RAID і використано як окремий, диски обчислювальних машин.

Бекап тривав майже добу і '''15 листопада 2009''' по його завершенні була перша спроба відновити втрачені суперблоки та дескриптори груп.
Можливий варіан з зміною опцій файлової системи, що було знайдено в інтернеті

 tune2fs -O sparse_super 0 /dev/vg0/tgv000
 tune2fs -O sparse_super 1 /dev/vg0/tgv000
 fsck

не спрацював, тому наступним радикальним варіантом використали опцію &lt;tt&gt;-S&lt;/tt&gt; в &lt;tt&gt;mke2fs&lt;/tt&gt;

 -S     Write  superblock  and  group  descriptors  only.   This  is  useful  if  all of the
               superblock and backup superblocks are corrupted, and a last-ditch recovery method is
               desired.   It  causes  mke2fs  to reinitialize the superblock and group descriptors,
               while not touching the inode table and the block and inode bitmaps.  The e2fsck pro-
               gram  should be run immediately after this option is used, and there is no guarantee
               that any data will be salvageable.  It is critical to specify the correct filesystem
               blocksize when using this option, or there is no chance of recovery.

Перший запуск цієї команди виглядав просто

 mkfs.ext3 -S -O sparse_super /dev/vg0/tgv000
 fsck

'''16 листопада 2009''' fsck триває, але занадто багато помилок, детальніший перегляд ситуації встановив, що попередня версія ОС, в якій форматували цей розділ мала інші значення по замовчуванню і іноди не співпали:( Це означало лише одне - все треба починати з нуля. Зупинено процес перевірки заздалегіть неправильного розділу і відновлення зі зробленого бекапу.

Відновився розділ до початкового стану до ранку '''17 листопада 2009'''. Знову спроба відновити суперблоки та дискриптори груп, вже акуратно зазначивши параметри, які б співпали з попереднім форматування розділу.

 mkfs.ext3 -S -O has_journal,ext_attr,resize_inode,dir_index,filetype,sparse_super,large_file -N 402653184 /dev/vg0/tgv000
 fsck

Знову ж таки такий самий довгий процес, і нажаль, на ранок '''18 листопада 2009''' ми побачили наступну помилку:

 Error storing directory block information (inode=18461770, block=0, num=20168): Memory allocation failed
 e2fsck: aborted

Використавши інший суперблок, і слідкуючи за використання пам'яті запустили &lt;tt&gt;fsck&lt;/tt&gt; знову. Слідкуючи, що з пам'яттю все нормально ввечері отримали таку саму помилку:( Відновлення з бекапу і наступний крайній метод.

Біля 12 години '''19 листопада 2009''' розділ знову відновлено до початкового стану. Відновлення вже інформації а не розділу за допомогою програми R-Linux - програми яка шукає на розділі фали і відновлює їх. Resque софт, який надає можливість пошукати і скопіювати файли &quot;що вцілили&quot;. Особливість програми - працює під ОС Windows, хоч і призначена для відновлення інформації з ext3 розділів. Тому було взято одну з нод кластеру, встановлено Windows7. На елементі збереження в свою чергу піднято iSCSI сервер, і користуючись вже встроєними можливостями цього релізу ОС Windows роботи з iSCSI підмонтовано розділ.

Перший процес - сканування, тобто пошук таких фалів, використовуючи всі методи та еврістики програми. Такий процес тривав 19 годин і знайшов багато файлів для відновлення '''20 листопада 2009'''. Особисто з моїх файлів дуже малий процент тих, які знаходяться на поганих інодах і не можуть бути відновлені, тому перспектива досить райдужна. 

Видалено бекап з дисків, які використовувались для цього призначення (адже відновлення інформації процес все-одно read-only, а місця куди відновити 3ТБ інформації немає. Запущено відновлення всіх можливих фалів, що можуть бути відновлені.

Довгий процес відновлення інформації, в першу чергу через необхідність постійного контролю і виявленню файлів, що некоректно відновилися. Через пошкоджені дискриптори, деякі файли, що мали реальний розмір декілька кілобайт сприймалися як екзобайти.

[[Файл:recovery-eb.png]]

Але ще гірше, коли це були гігабайти, які таки вміщалися на цільовому диску, куди відновлювалась інформація і місце закінчувалось через такі помилкові фали. Відновлення завершилось до ранку '''24 листопада 2009'''. 

Запущена перерозмітка рейд-масиву, пов'язана з планами на розширення, і подальше форматування LVM для створення чистої робочої файлової системи на новому Raid-Set.

'''25 листопада 2009''' закінчилась розмітка RAID-масиву. Загальна кількість жорстких дисків в RAID6 волумі - 12х400ГБ = 4000ГБ.
3.5ГБ відформатовано в ext4 безпосередньо для /home, 140ГБ вільного місця зарезервовано для LVM-snapshot, щоб створювати бекапи на стрімер, якщо він у нас таки буде:)

Копіювання відновлених даних на RAID, яке закінчилось вранці '''26 листопада 2009'''. Далі до вечора проводилась перевірка роботи системи, та тестування деяких нових можливостей, які можливо будуть впроваджені трохи згодом.

'''27 листопада 2009''' поновлено доступ користувачів на кластер.

Таким чином, маємо цікавий факт - після двох тижнів роботи дані нашого Linux-кластера вдалося врятувати за допомогою R-Linux під Microsoft Windows:)</rev>
        </revisions>
      </page>
      <page pageid="21" ns="0" title="Rules of Usage">
        <revisions>
          <rev xml:space="preserve">Для викладачів, співробітників, студетів, аспірантів та інших працівників Київського національного університету користування кластером є вільним при умові дотримання правил користування. Адмiнiстраторська група не проводить навчальних чи безпосередньо пов'язаних iз задачею користувача робiт, а лише забезпечує функціонування і розвиток кластера та доступ до нього. Для одержання додаткових послуг, таких як розпаралелювання чи оптимiзацiя алгоритму, навчання паралельним мовам програмування, написання скриптів запуску, консультації, тощо, необхiдною умовою є укладання договору з Iнформацiйно-обчислювальним центром, в якому обумовлюються види послуг та розмiр оплати.

'''Користувачі зобов'язані:'''
* дотримуватись чинних правил користування кластером;
* на вимогу адміністратора надавати звіт про виконану роботу та про затрачений процесорний час;
* інформувати адміністратора про проблеми в роботі кластера та програмного забезпечення;
* при публікації результатів, отриманих з використанням кластера, вказувати в публікаціях, що розрахунки проводились з використанням обчислювального кластера інформаційно-обчислювального центру Київського національного університету імені Тараса Шевченка, створеного за підтримки корпорації Інтел.

'''Користувачі мають право:'''
* проводити розрахунки, що стосуються наукової роботи, навчального процесу, проектів університету чи факультетів, а також роботи, що виконуються сторонніми користувачами за договорами університету.
* зберігати програмний код та отримані результати в межах виділеної квоти; адміністратор повинен заздалегідь інформувати про зміну максимального дискового простору, що виділяється для користувача;
* підвищувати власний рівень в галузі програмування та паралельних обчислень.

'''Забороняється:'''
* &lt;font color=red&gt;категорично заборонено&lt;/font&gt; передавати свій login та пароль іншим особам;
* використовувати кластер з метою, що не має відношення до наукової чи навчальної діяльності (ігри, створення власних мережевих серверів і т. ін.);
* використовувати кластер для доступу в інтернет;
* заважати нормальній роботі інших задач, що виконуються на кластері;
* виконувати дії,несанкціоновані адміністратором, що можуть призвести до виходу з ладу системи захисту кластера.</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>