From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Date: Mon, 28 Dec 2009 18:52:47 +0200 From: Michael Shigorin To: ALT Linux Community Message-ID: <20091228165246.GF3735@osdn.org.ua> Mail-Followup-To: ALT Linux Community , sysadmins@lists.altlinux.org References: <4B3846B9.2000500@generation.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B3846B9.2000500@generation.ru> User-Agent: Mutt/1.4.2.1i Cc: sysadmins@lists.altlinux.org Subject: Re: [Sysadmins] =?koi8-r?b?8MXSxdPP2sTBzsnFIFJBSUQtzcHT08nXwSAizsEg?= =?koi8-r?b?zMXU1SI=?= X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sysadmins@lists.altlinux.org List-Id: ALT Linux sysadmin discuss List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 16:53:03 -0000 Archived-At: List-Archive: On Mon, Dec 28, 2009 at 10:48:41AM +0500, Yakov Hrebtov wrote: > Недавно собрали сервер хранения данных на базе контроллера > Adaptec 51645 и 16 2TB дисков. Из 15 дисков сделали RAID5, а > 16-й - Hot Spare. Мысль о том что для массива с таким большим > количеством дисков пожалуй более подойдет RAID6 пришла после > того, как сервер уехал в другой город (туда, где он и должен > работать) :-) В контроллерах Adaptec заявлена возможность RAID > level migration. Я решил сконвертировать RAID5 на 15 дисках в > RAID6 на 16 дисках. При возможности я бы всё-таки оставил и hot spare -- особенно если диски вне массива не тестировались на разброс параметров. > Запустил процесс с помощью утилиты arcconf. Проблема в том, > что процесс преобразования достиг 1% через четверо суток :) > Видимо какая-то ошибка в контроллере, потому что совершенно > непонятно, чем можно так долго заниматься. В поддержку Адаптека > написал, но пока без ответа. Сейчас массив работает, но с > ужасной скорость ~30M/s. > > Думаю, что теперь делать... Задача - удаленно справиться с этой > проблемой. Система стоит прямо на массиве к сожалению. Данных > на сервере естественно пока нет. По-хорошему бы засунуть туда мелкий SSD и систему на него, только /var/log на сторадж. Есть 1.8"/2.5" SATA и по размеру разъёма IDE, только осторожно с Transcend -- эти умники сделали обечайку недостаточного размера, очень легко промахнуться на один пин и при этом поделие сгорает. > Идея у меня следующая: > 1. Замонтировать tmpfs. > 2. отключить своп. > 3. rsync-ом залить в tmpfs всю систему (памяти хватит). > 4. сделать chroot в точку монтирования tmpfs Возможно, понадобится pivot_root, и не уверен, что корневая отпустится. Но если утилита на это внимания не обратит, то сюрприз может ожидать уже на этапе попытки разбить новый массив. > 5. удалить существующий массив. и создать с нуля RAID6. > 6. залить систему из tmpfs назад на массив. > 7. Установить загрузчик. > 8. Попробовать перезагразиться. > > Как считаете, есть шансы на успех? :-) > Может кто-то предложит другой вариант? Я бы постарался обсудить командировку с отдельным диском для системы и возможностью решить спокойно на месте. Если же нет -- то искал бы возможность подключить IP KVM. Если нет -- высунул тот диск, который spare, как JBOD и попытался переехать на него (это если удастся удачно остановить процесс миграции). А потом его бы и засунул назад как опять запасной. 2 rider: ну и что SoL даст, у нас есть текстовый инсталятор? :( Хотя сейчас около многих IPMI BMC по факту интегрирован сервисный процессор (например, на новых супермикрах, которые две дуальных в 2U становятся) -- надо глянуть описание материнки. PS: с такими вопросами приглашаю в sysadmins@. :) -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/