Mertvii
30-09-2011, 05:36
На сервере (вин2к3р2сп2) установлен рэйд контроллер в виде pci-платы, promise fasttrak TX2650. На нём висит 2 300Гб однопластиновых одинаковых самсунга (кэш отключён), формируя зеркало рэйд1
Проблема: постоянные сообщения об обнаруженной inconsistency, рассогласовании, то бишь. Т.е. заходишь на сервер с утра, а тебе целая гора табличек - обнаружено рассогласование зеркала по адресу LBA 0x01128e7bfd и т.д.
Обнаружилось достаточно давно и проявлялось регулярно. У сопровождающего софта есть возможность проверки зеркала собственными средствами (вебинтерфейс на жаве, где можно по расписанию запускать проверку согласованности зеркала, а так же проверку поверхности его отдельных дисков), что и было сразу выполнено: проверка физ. поверхности дисков показала отсутствие повреждений, проверка согласованности зеркала выдала опять сообщения об inconsistency, НО - адреса были немного другие. Это было немного неожиданно - как такое может быть? Если таки есть повреждённые участки, то они должны всегда находиться по одному и тому же LBA. Но вроде бы как оно без проблем работало, физ. повреждений не обнаружилось даже при проверки каждого диска отдельно victoria-ей, и на некоторое время проблему отложили в долгий ящик, засунув регулярную проверку на consistency в шедулер, чтобы наблюдать в развитии.
По итогам 2 месяцев, имеем общую картину лога такой проверки:
1) Все сообщения о inconsistency укладываются в первые 10Гб системного раздела, на остальных 290Гб пространства никогда не находит.
2) Сперва идёт группа ВСЕГДА одних и тех же адрессов, их количество почти не меняется, в районе первых 750Мб дискового пространства (принимая 1LB равным 512Байт), примерный размер такой "зоны несогласия" - 80 секторов
3) Затем идёт набор ВСЕГДА РАЗНЫХ адресов, причём записей разное количество
4) Опять ВСЕГДА постоянная группа адресов, в районе первых 9Гб дискового пространства.
Как это интерпретировать я не совсем понимаю
Другая проблема с этим зеркалом - это ошибки вроде "Ошибка отложенной записи", источник - ntfs. Проявляется при превышении некой планки интенсивности операций записи - т.е. если начать сильно нагружать диск на запись, в логах начинает всплывать эта ошибка каждые 10 минут, и через 30-120 минут начинаются несовместимые с жизнью тормоза, отваливается сеть, скорость вообще всех дисковых операций, даже не связанных с этим зеркалом падает в 0 (что-то очень похожее я наблюдал на виндовсХП при некорректном отключении на горячую SATA-диска) Лечится только ребутом. Если не нагружать на запись - работает без проблем, кроме одного "но" - пару раз за это время накрылись журналы службы репликации файлов. Связано ли это с вышеуказанными проблемами не известно.
Стоит добавить, что неожиданные отключения света - норма в тех местах. ИБП у сервера дешёвый и слабо управляемый, и не всегда отключает его в штатном режиме, часто просто обрубая ему питание до окончания штатной процедуры выключения.
Может ли кто-то поделиться опытом в данном вопросе?
На данный момент планируется подключение обоих дисков зеркала к другой машине и их сверка сторонним средствами, чтобы убедиться, что рассогласование действительно есть и это не глюк софта мониторига от промиса.
Так же хотелось бы понять что имено располагается по адресам, которые не меняются из лога в лог, быть может это прольёт свет на ситуацию. Есть ли утилита, понимающая структуру системных файлов нтфс и способная по заданному LBA провести в них поиск и выдать имя файла, к которому он относится?
Проблема: постоянные сообщения об обнаруженной inconsistency, рассогласовании, то бишь. Т.е. заходишь на сервер с утра, а тебе целая гора табличек - обнаружено рассогласование зеркала по адресу LBA 0x01128e7bfd и т.д.
Обнаружилось достаточно давно и проявлялось регулярно. У сопровождающего софта есть возможность проверки зеркала собственными средствами (вебинтерфейс на жаве, где можно по расписанию запускать проверку согласованности зеркала, а так же проверку поверхности его отдельных дисков), что и было сразу выполнено: проверка физ. поверхности дисков показала отсутствие повреждений, проверка согласованности зеркала выдала опять сообщения об inconsistency, НО - адреса были немного другие. Это было немного неожиданно - как такое может быть? Если таки есть повреждённые участки, то они должны всегда находиться по одному и тому же LBA. Но вроде бы как оно без проблем работало, физ. повреждений не обнаружилось даже при проверки каждого диска отдельно victoria-ей, и на некоторое время проблему отложили в долгий ящик, засунув регулярную проверку на consistency в шедулер, чтобы наблюдать в развитии.
По итогам 2 месяцев, имеем общую картину лога такой проверки:
1) Все сообщения о inconsistency укладываются в первые 10Гб системного раздела, на остальных 290Гб пространства никогда не находит.
2) Сперва идёт группа ВСЕГДА одних и тех же адрессов, их количество почти не меняется, в районе первых 750Мб дискового пространства (принимая 1LB равным 512Байт), примерный размер такой "зоны несогласия" - 80 секторов
3) Затем идёт набор ВСЕГДА РАЗНЫХ адресов, причём записей разное количество
4) Опять ВСЕГДА постоянная группа адресов, в районе первых 9Гб дискового пространства.
Как это интерпретировать я не совсем понимаю
Другая проблема с этим зеркалом - это ошибки вроде "Ошибка отложенной записи", источник - ntfs. Проявляется при превышении некой планки интенсивности операций записи - т.е. если начать сильно нагружать диск на запись, в логах начинает всплывать эта ошибка каждые 10 минут, и через 30-120 минут начинаются несовместимые с жизнью тормоза, отваливается сеть, скорость вообще всех дисковых операций, даже не связанных с этим зеркалом падает в 0 (что-то очень похожее я наблюдал на виндовсХП при некорректном отключении на горячую SATA-диска) Лечится только ребутом. Если не нагружать на запись - работает без проблем, кроме одного "но" - пару раз за это время накрылись журналы службы репликации файлов. Связано ли это с вышеуказанными проблемами не известно.
Стоит добавить, что неожиданные отключения света - норма в тех местах. ИБП у сервера дешёвый и слабо управляемый, и не всегда отключает его в штатном режиме, часто просто обрубая ему питание до окончания штатной процедуры выключения.
Может ли кто-то поделиться опытом в данном вопросе?
На данный момент планируется подключение обоих дисков зеркала к другой машине и их сверка сторонним средствами, чтобы убедиться, что рассогласование действительно есть и это не глюк софта мониторига от промиса.
Так же хотелось бы понять что имено располагается по адресам, которые не меняются из лога в лог, быть может это прольёт свет на ситуацию. Есть ли утилита, понимающая структуру системных файлов нтфс и способная по заданному LBA провести в них поиск и выдать имя файла, к которому он относится?