Виртуальная файловая система виртуальной машины может занимать несколько терабайт. Легко. В массовом хостинге таких систем на одном СХД может быть много. Тоже легко.
Финансово невыгодно. Три может быть разумно, если ты хочешь вынуть диск из рабочего массива. Умножаешь количество реплик, ждёшь синхронизации, потом убираешь лишний диск и понижаешь весь массив.
RAID10 читается как "raid one zero" - это синтез RAID1(mirror) и RAID0(stripe).
RAID5 это минимум 3 диска с распределённой контрольной суммой. 4-й диск добавляют редко, его использовать можно либо как hot spare, либо как дополнительное хранилище для контрольной суммы. Но в последнем случае лучше использовать…
RAID6 это 2n дисков (не менее 4) с распределённой И ОТЗЕРКАЛЕННОЙ контрольной суммой.
Так понятнее? И вообще, статья на педивикии достаточно полно раскрывает тему для чайников.
Потому что схемы хранения аналогичны по архитектуре. И там, и там используется 2x2 диска, и там и там отказоустойчивость приближается к n/2. Но если в RAID10 у вас откажут ОБА зеркала разом, можете помахать вашим данным ручкой. В RAID6 у вас могут отказать два ЛЮБЫХ диска, и всё равно есть шансы полностью восстановить данные. При увеличении количества дисков в массиве, надёжность RAID10 стремительно падает (или, точнее, непропорционально медленно растёт), в то время, как надёжность RAID6 почти не снижается. Про RAID5 даже говорить не стоит, ещё 8 лет назад доказано, что при современных объёмах дисков RAID5 ненадёжен в принципе.
Вы мухлюете. RAID6, как и RAID10, обеспечивает полное дублирование данных.
Незначительная просадка по скорости при ребилде RAID6 компенсируется наличием CRC, что позволяет нивелировать BER (именно из-за отсутствия контрольных сумм ваш RAID10 ТОЧНО будет выдавать неверные данные при длительной эксплуатации).
Там немного другая ситуация. Могу рассказать историю, как проработавший 7 лет без остановки почтовый сервер перенесли в другое здание и он отказался загружаться. Слава богу, повертевшись пол-часа вхолостую, диски согрелись, головка спозиционировалась на корректные дорожки и система всё таки загрузилась.
Только теоретически. Практически, это глупо и небезопасно.
Он меня наоборот неоднократно спасал
Представим вполне себе негипотетическую ситуацию перманентного облома сервиса в определённой ситуации. В определённый момент эта ситуация начинает повторяться с завидной периодичностью. init-демон начинает перезагружать сервис N'дцать раз в минуту, при этом системные извещения о подобной проблеме не продуманы либо просто отказали. В итоге сервис работает 5 секунд, даже что-то делает, и снова валится. А ты об этом узнаёшь через пару недель (в лучшем случае!), когда тебе самому понадобился функционал, вызывающий падение.
Откуда systemd узнает, что какая-то левая машина где-то там в сети поднялась и работает? Это баг конкретно модуля, что он при старте, без всякой надобности, лезет на LDAP (#1) и полностью крашит старт сервера, если LDAP не ответил (#2). Я поначалу пробовал откладывать старт остальных контейнеров на "после AD DC", но потом просто забил и перезагружаю nginx на проксе через 5 минут по таймеру. Из-за одного тупого модуля задерживать стартап всей системы как-то тупо. Не находите? Дойдут руки, переделаю авторизацию на auth_subrequest и отвяжусь от этой зависимости. И, да, баг в репо модуля на этот счёт висит не первый год. "Всем по…"
Значит, нарушен порядок загрузки. У меня аналогичная проблема - модуль ngx_auth_ldap при старте зачем-то лезет на LDAP сервер, и если сервер не ответил - убивает весь процесс. При этом на момент старта не факт, что вообще есть сеть, а даже если есть - не факт, что LDAP сервер успел обнюхаться и начать принимать запросы. Пока приходится руками перезапускать nginx после установки сети, но надо будет полностью отказаться от этого недоделка и перейти на ngx_auth_subrequest. Но это не причина ругать systemd, который просто не может знать, что там творится ВНЕ его зоны ответственности. Вам нужно особое поведение - `systemctl edit имяюнита` и пишите любое особое поведение. Например, вставляйте prestart скрипт, который будет проверять, что все необходимые сервисы не просто запущены, а полностью поднялись и реально отвечают на запросы.
Не передёргивайте. И учите историю для начала разговора. Уже давно было очевидно, что, в случае конфликта с мировой системой, в первую очередь под ударом окажутся структуры, от этой системы зависящие. Поэтому внутренние расчёты были переведены на внутреннюю ПОДсистему (виза и мастеркард до сих пор работают локально), а потом разработана собственная.
Не в Linux, а в bash.
Виртуальная файловая система виртуальной машины может занимать несколько терабайт. Легко. В массовом хостинге таких систем на одном СХД может быть много. Тоже легко.
Финансово невыгодно. Три может быть разумно, если ты хочешь вынуть диск из рабочего массива. Умножаешь количество реплик, ждёшь синхронизации, потом убираешь лишний диск и понижаешь весь массив.
В аппаратном контроллере, предполагаю, очень упрощённые алгоритмы. Печально.
Бредите. Правда. Что значит "сможет-не сможет" ? Это "ну нишмагла я…" что ли?
RAID10 читается как "raid one zero" - это синтез RAID1(mirror) и RAID0(stripe).
RAID5 это минимум 3 диска с распределённой контрольной суммой. 4-й диск добавляют редко, его использовать можно либо как hot spare, либо как дополнительное хранилище для контрольной суммы. Но в последнем случае лучше использовать…
RAID6 это 2n дисков (не менее 4) с распределённой И ОТЗЕРКАЛЕННОЙ контрольной суммой.
Так понятнее? И вообще, статья на педивикии достаточно полно раскрывает тему для чайников.
Потому что схемы хранения аналогичны по архитектуре. И там, и там используется 2x2 диска, и там и там отказоустойчивость приближается к n/2. Но если в RAID10 у вас откажут ОБА зеркала разом, можете помахать вашим данным ручкой. В RAID6 у вас могут отказать два ЛЮБЫХ диска, и всё равно есть шансы полностью восстановить данные. При увеличении количества дисков в массиве, надёжность RAID10 стремительно падает (или, точнее, непропорционально медленно растёт), в то время, как надёжность RAID6 почти не снижается.
Про RAID5 даже говорить не стоит, ещё 8 лет назад доказано, что при современных объёмах дисков RAID5 ненадёжен в принципе.
Вы мухлюете. RAID6, как и RAID10, обеспечивает полное дублирование данных.
Незначительная просадка по скорости при ребилде RAID6 компенсируется наличием CRC, что позволяет нивелировать BER (именно из-за отсутствия контрольных сумм ваш RAID10 ТОЧНО будет выдавать неверные данные при длительной эксплуатации).
Там немного другая ситуация. Могу рассказать историю, как проработавший 7 лет без остановки почтовый сервер перенесли в другое здание и он отказался загружаться. Слава богу, повертевшись пол-часа вхолостую, диски согрелись, головка спозиционировалась на корректные дорожки и система всё таки загрузилась.
Это всё тривиально отключается в настройках. Причём, если мне не изменяет память, одной галочкой.
А что же он США не заблокирует, которые финансируют эту войну?
Поставь 5.6 с официального сайта.
Только теоретически. Практически, это глупо и небезопасно.
Представим вполне себе негипотетическую ситуацию перманентного облома сервиса в определённой ситуации. В определённый момент эта ситуация начинает повторяться с завидной периодичностью. init-демон начинает перезагружать сервис N'дцать раз в минуту, при этом системные извещения о подобной проблеме не продуманы либо просто отказали. В итоге сервис работает 5 секунд, даже что-то делает, и снова валится. А ты об этом узнаёшь через пару недель (в лучшем случае!), когда тебе самому понадобился функционал, вызывающий падение.
Мне казалось, это очевидно, что LDAP сервер - отдельная машина.
Restart=always - это готовый рецепт катастрофы. Никогда так не делайте.
Откуда systemd узнает, что какая-то левая машина где-то там в сети поднялась и работает? Это баг конкретно модуля, что он при старте, без всякой надобности, лезет на LDAP (#1) и полностью крашит старт сервера, если LDAP не ответил (#2). Я поначалу пробовал откладывать старт остальных контейнеров на "после AD DC", но потом просто забил и перезагружаю nginx на проксе через 5 минут по таймеру. Из-за одного тупого модуля задерживать стартап всей системы как-то тупо. Не находите? Дойдут руки, переделаю авторизацию на auth_subrequest и отвяжусь от этой зависимости. И, да, баг в репо модуля на этот счёт висит не первый год. "Всем по…"
Большим минусом Nexcloud является его жёсткая привязка к Apache HTTPD. Чтобы его отвязать, приходится делать миллион приседаний.
А можно было писать код нормально…
Значит, нарушен порядок загрузки. У меня аналогичная проблема - модуль
ngx_auth_ldapпри старте зачем-то лезет на LDAP сервер, и если сервер не ответил - убивает весь процесс. При этом на момент старта не факт, что вообще есть сеть, а даже если есть - не факт, что LDAP сервер успел обнюхаться и начать принимать запросы. Пока приходится руками перезапускать nginx после установки сети, но надо будет полностью отказаться от этого недоделка и перейти наngx_auth_subrequest. Но это не причина ругать systemd, который просто не может знать, что там творится ВНЕ его зоны ответственности. Вам нужно особое поведение - `systemctl edit имяюнита` и пишите любое особое поведение. Например, вставляйте prestart скрипт, который будет проверять, что все необходимые сервисы не просто запущены, а полностью поднялись и реально отвечают на запросы.Не передёргивайте. И учите историю для начала разговора. Уже давно было очевидно, что, в случае конфликта с мировой системой, в первую очередь под ударом окажутся структуры, от этой системы зависящие. Поэтому внутренние расчёты были переведены на внутреннюю ПОДсистему (виза и мастеркард до сих пор работают локально), а потом разработана собственная.
НСПК начали разрабатывать не "вовремя" а "заранее". Не тупите хотя бы сейчас. Всё было спланировано.
Не путайте технологию и сопровождающие инструменты. Сама технология контейнеризации напрямую с докерХАБОМ не связана.