- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
А зачем мне смотреть то что я и так хорошо знаю
Потому и советую RAID-10 ;)
Кстати, у RAID10, при благоприятном стечении обстоятельств, без потери информации может вылететь 2 диска из 4. После кончины первого диска, вероятность того, что RAID продолжит работать при выходе второго диска из строя, составляет 66% 😂
Статья на хабре поднимает ещё один интересный вопрос. RAID 1 и RAID 10 не могут распознать повреждение данных, то есть если диски рассинхронизированы, определить кто из них содержит верные данные нельзя. В случае с RAID5/6 - можно, так что для ответственных приложений RAID10 непригоден.
Pilat, Средства контроля данных в самом диске тоже есть и достаточно надежны.
Пожалуй, это может происходить только при частых внезапных перезагрузках в ужасном ДЦ, когда не на все диски успевает записаться информация. В этом случае есть контроллеры с батарейкой и с некоторых пор в mdadm появился скрипт сверяющий массив раз в месяц.
В centos, как обычно, не появился :)
И еще там в комментах вспомнили, что на практике raid5 не делает сверку при чтении. То есть, при определении самого факта ошибки в данных ДАЖЕ в случае с raid5 на практике полагаются на внутренние механизмы диска.
Pilat, вообще, там в конце статьи образовались дописки :) И кучу всего поперечеркали )
Статья на хабре поднимает ещё один интересный вопрос. RAID 1 и RAID 10 не могут распознать повреждение данных, то есть если диски рассинхронизированы, определить кто из них содержит верные данные нельзя. В случае с RAID5/6 - можно, так что для ответственных приложений RAID10 непригоден.
Это всё теория. Есть хостеры (и не один), которые годами работают с RAID-10 и восстанавливают информацию успешно при проблемах с дисками. Думаю, что давно бы уже отказались от него, если бы всё было так плачевно на практике.
и с некоторых пор в mdadm появился скрипт сверяющий массив раз в месяц.
В centos, как обычно, не появился :)
Может потому, что crontab добавили не в mdadm, а в дебиановский пакет? :) Штатная возможность проверки дисков есть и в centos - скрипт checkarray просто обращается к файлам в /sys/ для ее запуска.
Himiko, они просто не знают. Тут ведь как повезет. После внезапного пропадания питания я наблюдал не чинящуюся файловую систему на рассинхронизировавшихся дисках.
myhand, да, действительно. я имею ввиду что скрипт checkarray появился в mdadm 3, но centos его конечно же не включает в новые версии. С собственным скриптом тоже неплохой вариант.
Тогда неужели никто эти логи не читает и не замечает рассинхронизации ?
в дебиане тоже какая-то 2.x версия mdadm.
Himiko, они просто не знают. Тут ведь как повезет. После внезапного пропадания питания я наблюдал не чинящуюся файловую систему на рассинхронизировавшихся дисках.
Ну я сомневаюсь, что в компании, которая работает более 5 лет об этом не знают :)
Реально встречал любителей RAID-10 среди крупных компаний с большими сроками работы.