Никаких намеков, говорю прямо. Могу объяснить подробней:
1. Задержка операции критична для задачи в том случае, если задача блокируется, ожидая завершения операции.
2. Большинство современных приложений удовлетворяет асинхронная запись, разве что самую критическую часть они могут записывать синхронно — т.е. основное число операций записи выполняется без блокировки задачи.
3. Чтение же почти всегда вызывает блокировку, т.е. если нужно обработать целый объем данных, пока он не будет в наличии полностью, задача не может выдать результат.
Самый типичный пример — СУБД или файловые системы с журналом транзакций.
Тут основной упор был на безостановочный ресайз. Сейчас, кстати, достаточно разумным компромисом его дает thin provisioning. Для остановочного, да — lvm и resizefs вполне хорошо справляются.
Со всем согласен, кроме этого: По этой самой причине абсолютно не имеет смысла привносить слабую окраску в нейтрально окрашенные элементы интерфейса — мозг сведет эти старания обратно к нейтральным цветам.
Поле зрения не ограничено только страницей сайта или приложения. Кроме дизайна часто есть еще и графический контент, фотографии, имеющие свои цветовые гаммы; вокруг дисплея есть мир — комната, улица и т.д со своими цветами; есть другие сайты или приложения, на которые пользователь часто переключается. Все эти вещи сводят на нет приспосабливание к постоянному цвету, т.к. цвета все время меняются. Приспосабливание будет только для редких случаев — например, длительного чтения текста.
Да, вариант не самый вероятный. А накрылось у работающего сервера или по какой-то причине его нужно было перезагрузить и проблема стала видна после перезагрузки?
Если была перезагрузка при работах, то не стоит однозначно связывать проблему с работами. У нас, однажды, после плановых работ, во время которых штатно шатдаунились и потом запускались машины, стали жаловаться клиенты, что мы им все поломали. У кого-то сайт не работает, у кого-то почта, у кого-то ОС не грузилась. У всех окащалось, что они стартовали какие-то сервисы вручную и не сохраняли в конфигурацию на диск. При перезагрузке, соответственно, старт не выполнялся и сервис не работал. Проблема была в неполной настройке администраторами клиентов, но проявилась она только после наших плановых работ.
По поводу «многими причинами (в том числе длительной эксплуатацией без регулярного обслуживания с клиентской стороны» они правы, такое тоже бывает, но как-то криво и путано они это выразили.
Можно сказать, это такой негативный эффект длительного аптайма — допустим, сервер работает год-два без остановки, если есть какие-то мелкие проблемы в системе, которые чуть-чуть повреждают данные, (чаще всего, это баги где-то на уровне драйверов диска, файловой системы). Обычно это бывает с мета-данными — в записываемых на диск данных могут копиться повреждения. в то время как в оперативной памяти ОС все может видиться нормально. И только после перезагрузки, когда все данные пришлось загружать с диска, становятся видимыми повреждения.
Под регулярным обслуживанием скорее всего имеют в виду проверку целостности файловой системы. Она выполняется автоматически при загрузке сервера и пока повреждения метаданных незначительные, они могут легко восстанавливаться автоматически. Но если ошибки долго копились, они достигают критической массы и возникают непоправимые повреждения.
Основные минусы:
1. Не решаемый: у людей разгибания пальцев (движение вверх) и отклонения наружу в бок физиологически не являются частой и нужной операцией, поэтому эти движения получаются менее точными, медленнее, слабее. Оно, конечно, натренировывается постепенно, но все-равно большая разница между движениями в других направлениях.
2. Слишком часто нужно переключаться между режимами — приходится держать в голове режим, и терять время на переключение. Это было бы решаемо доработкой клавиатуры.
3. С vim работать совершенно не удобно. А менять мэппинг vim и долго себя переучивать было лишним, учитывая другие недостатки.
И надежность обеспечить можно, и диск при необходимости по-живому мигрировать. Зависит от постановки задачи при проектировании и, разумеется, адекватности созданного проекта и выбранных инструментов.
Я так понимаю, у Scalaxy сейчас не в штатном режиме система поломалась, а что-то меняли, и сломалось во время изменения.
Клиента можно шейпить на том же основании, на котором ему может быть не предоставлено процессорное время или увеличение оперативной памяти. Это вопрос не техничесикй, а формулировки в договоре.
По поводу того, куда зашел спор, не стоит писать это мне. Я спорю о другом. Amarao утверждает, что проблема, когда клиент съедает много места и вредит остальным клиентам, является проблемой thin provisioning. Я возражаю тем, что это проблема конкретной реализации хранилища и существует много способов решения проблемы. которые от thin provisioning не зависят.
И, да, на тот случай, если шейпера нет, а защитить соседей хочется, то достаточно после пересечения порога блокировать запись только для «опасного» клиента. Но это я уже тоже писал раньше.
Такое ощущение, что вы у меня все это время одно слово из десяти читаете. Или лень чуть-чуть подумать. Я уже писал об это раз пять. Давайте я последний раз напишу. Если и сейчас останется непонятно, закрываем тему и буратины остаются сами себе теми, кто есть.
Когда ререзв становится меньше порога, начинать шейпить того клиента, потребление которого грозит исчерпать резевр быстрее, чем сделается апгрейд. Если он не один, то шейпить всех, у кого потребление превышает «нормальное». Соседи не страдают вообще. А тот или те, кто стали вдруг очень много писать, замедлятся, чтобы для них успели нарастить хранилище.
Если ситуация, когда нужно шейпить и апгрейдить, случается часто, это означает одну хорошую вещь и одноу плохую. Хорошая — продажа услуги быстро растет. Плохая — тот, кто планирует резерв, неоправданно его жмотит. Когда клиенты каждую субботу сжирают по 2 Тб за три часа, глупо держать резевр 2 Тб. Можете воспользоваться самостоятельно той формулой, для расчета запаса, которую я уже давал — добавьте в нее еще эти 2 Тб в неделю.
Для этого всего нужен QoS или просто шейпинг. Но если у вас шейпинг невозможно или трудно реализовать, то это не проблема thin provisioning как модели, а проблемы вашей конкретной реализации хранилища.
Сценарий и реализация — совершенно разные вещи. В разных реализациях худшие сценарии могут сильно отличаться. Чтобы не попадать часто в аварийный режим, выбирать хорошую реализацию, в которой худший сценарий даст минимальный ущерб.
Про 20 Тб — это просто так за число зацепился. Порог и прочее по задаче можно точнее считать. Например, если вы уже знаете, что средняя скорость роста объема данных для вас за последний месяц составила 100 Гб в день, время добавления в СХД новых 10 Тб составляет 7 дней, то запас свободного места должен быть достаточным для того, чтобы без спешки успеть провести апгрейд и учетом рисков поставки оборудования невовремя или задержек по другим причинам. Скажем, считать что на апгрейд требуется 20 дней. Тогда порог срабатывания должен быть 2 Тб остатка. Схема общая, ее можно еще в зависимости от условий усложнять.
Вас злой демон заставляет реализовать самый плохой вариант? Проявите благоразумие, выбирайте хороший вариант. Тем более, даже думать можно не трудиться, я его уже вам писал ранее.
Блокируйте или ставьте шейпер на проблемного клиента в тот момент, когда срабатывает порог минимального запаса, 10%-20%. Как определить, кто проблемный? Элементарно. Тот, кто при экстраполяции потребления исчерпает ресурс быстрее, чем будет возможно его нарастить. Если лень с математикой заморачиваться, просто считать проблеными лидеров по росту потребления диска за последний день.
Если хотите показать недостатки thin provisioning, давайте, поспорьте с этим вариантом. Не нужно залезать на посторонние шкафы и спорить с тем, что будет видно с них.
Кроме того, общая проблема thin provision — oversubscription не может быть решена. Никакими средствами с точки зрения платформы виртуализации.
Я указал уже три рабочих варианта, а вы — «не может быть решена». И упорно гнобите thin provisioning вообще, в то время как ограничение касается только выбранной вами реализации.
Понятно, что если какую-то функцию не хочется реализовывать или просто сложно, то можно найти сотню других причин, объясняющих, почему это не надо делать. Возводить при этом напраслину на технологии — это какая-то мелкая подлость. Достаточно сказать, экономический эффект не ясен — бюджет на такую переделку не предусмотрен.
Кстати, специальной файловой системой заниматься смысла тоже не больше. Она может быть и переживет невыделение места, а mysqld при проблеме записи может падать точно также аварийно.
Какое многозначное слово «физический». Не можете физически, потому что обещано и будет нарушение договора, или не можете, потому что технически невозможно в используемом вами хранилище?
Только, пожалуйста, не нужно привлекать к ответственности ни в чем не повинную модель thin provisioning. Она на то и модель, концепция одного аспекта организации хранилища, и не создает технических ограничений.
То, что XCP не дает готового механизма защиты от переполнения при коммите в TP, не означает того, что это технически невозможно. Вполне себе заурядная задача по допиливанию.
Сейчас вы говорите, что один создаст проблему всем. Я приводил раньше элементарное решение на этот случай и получил на это возражение «3) Я не могу ограничить клиента, потому что ему это уже было обещанно.» Где логика?
Если не случилось додумать решение, объясню подробнее:
Скажем, есть N клиентов, есть запас 20 Тб. Один клиент стал писать чудесным образом 500 Мб/сек и за 3 часа записал 5 Тб, свободных осталось 15 Тб.
Умные скрипты мониторинга видят, что дело грозит бедой и начинают ограничивать запись того одного, кто пишет так много. Можно самым простым способом — давать ему ошибку на запись, можно чуть сложнее — поставить для него шейпер записи на 1 Мбайт/сек. Можно еще проще — шейпить по скорости записи всех, но так лучше не делать.
Если я правильно понимаю:
1) В итоге от 90% клиентов, пострадавших от thin provisioning, разговор пришел к одному пострадавшему, которому может не получится записать 20 Тб за пол-дня.
2) Главным препятствием реализации биллинга по потреблению диска является забота об этом гипотетическом клиенте, то, что у вас для него нет красивого решения.
3) Претензий к схеме thin provisioning самой по себе нет.
Не понимаю, зачем было делать так сложно, но, не буду спорить, вероятно, вам так удобнее.
Достаточно было сразу честно сказать, что из-за особенностей вашей дисковой системы это трудно или невозможно реализовать, а не придумывать мифические недостатки thin provisioning. У которой есть, разумеется, свои минусы, но совсем не те, о которых вы сейчас говорите.
Желающему записать 20 Тб при скорости 100 Мбайт/сек понадобится больше двух суток. То, что при этом у всех его соседей будет ощутимо тормозить диск и уже это будет деградацией сервиса, другой вопрос.
Но зачем вы решили, что при коммите одного обязательно должны пострадать все? Ограничьте только клиента, который вдруг решил исчерпать хранилище. Скажите ему заранее, еще задолго до того, как все заполнится, что все, не можете дать больше. Ведь если он памяти сотню гигов запросит, то же самое ему скажете.
По какой схеме это делать, можете и сами додумать.
Теперь понятно. Из предыдущих возражений больше следовало, что вы в принципе считаете, что так делать неправильно, а не то, что это ограничение вашей реализации дисковой системы.
Нет, не логично. Никакой фундаментальной разницы. Все зависит от скорости деградации и реакции на нее.
Если вы не будете следить за сетью и потери доползут до 20%, это будет «всё» с большой буквы — отказ. Если будете недодавать памяти, то наступившие у клиентов убийства процессов из-за Out of Memory могут безвозвратно порушить данные. Если у клиента посещаемость вырастет в 10 раз, а вы ему не дадите процессора, это отнюдь не будет терпимо, его машина просто ляжет. А при невозможности записи на диск при журналируемой FS с работающими барьерами, авария будет ничуть не серьезнее.
Для дисков достаточно считать деградацией, требующей наращивания ресурсов, понижение свободного пространства, до, скажем, 20% с расстрелом допустившего понижение до 5%.
1. Задержка операции критична для задачи в том случае, если задача блокируется, ожидая завершения операции.
2. Большинство современных приложений удовлетворяет асинхронная запись, разве что самую критическую часть они могут записывать синхронно — т.е. основное число операций записи выполняется без блокировки задачи.
3. Чтение же почти всегда вызывает блокировку, т.е. если нужно обработать целый объем данных, пока он не будет в наличии полностью, задача не может выдать результат.
Самый типичный пример — СУБД или файловые системы с журналом транзакций.
По этой самой причине абсолютно не имеет смысла привносить слабую окраску в нейтрально окрашенные элементы интерфейса — мозг сведет эти старания обратно к нейтральным цветам.
Поле зрения не ограничено только страницей сайта или приложения. Кроме дизайна часто есть еще и графический контент, фотографии, имеющие свои цветовые гаммы; вокруг дисплея есть мир — комната, улица и т.д со своими цветами; есть другие сайты или приложения, на которые пользователь часто переключается. Все эти вещи сводят на нет приспосабливание к постоянному цвету, т.к. цвета все время меняются. Приспосабливание будет только для редких случаев — например, длительного чтения текста.
Если была перезагрузка при работах, то не стоит однозначно связывать проблему с работами. У нас, однажды, после плановых работ, во время которых штатно шатдаунились и потом запускались машины, стали жаловаться клиенты, что мы им все поломали. У кого-то сайт не работает, у кого-то почта, у кого-то ОС не грузилась. У всех окащалось, что они стартовали какие-то сервисы вручную и не сохраняли в конфигурацию на диск. При перезагрузке, соответственно, старт не выполнялся и сервис не работал. Проблема была в неполной настройке администраторами клиентов, но проявилась она только после наших плановых работ.
Можно сказать, это такой негативный эффект длительного аптайма — допустим, сервер работает год-два без остановки, если есть какие-то мелкие проблемы в системе, которые чуть-чуть повреждают данные, (чаще всего, это баги где-то на уровне драйверов диска, файловой системы). Обычно это бывает с мета-данными — в записываемых на диск данных могут копиться повреждения. в то время как в оперативной памяти ОС все может видиться нормально. И только после перезагрузки, когда все данные пришлось загружать с диска, становятся видимыми повреждения.
Под регулярным обслуживанием скорее всего имеют в виду проверку целостности файловой системы. Она выполняется автоматически при загрузке сервера и пока повреждения метаданных незначительные, они могут легко восстанавливаться автоматически. Но если ошибки долго копились, они достигают критической массы и возникают непоправимые повреждения.
Основные минусы:
1. Не решаемый: у людей разгибания пальцев (движение вверх) и отклонения наружу в бок физиологически не являются частой и нужной операцией, поэтому эти движения получаются менее точными, медленнее, слабее. Оно, конечно, натренировывается постепенно, но все-равно большая разница между движениями в других направлениях.
2. Слишком часто нужно переключаться между режимами — приходится держать в голове режим, и терять время на переключение. Это было бы решаемо доработкой клавиатуры.
3. С vim работать совершенно не удобно. А менять мэппинг vim и долго себя переучивать было лишним, учитывая другие недостатки.
Я так понимаю, у Scalaxy сейчас не в штатном режиме система поломалась, а что-то меняли, и сломалось во время изменения.
По поводу того, куда зашел спор, не стоит писать это мне. Я спорю о другом. Amarao утверждает, что проблема, когда клиент съедает много места и вредит остальным клиентам, является проблемой thin provisioning. Я возражаю тем, что это проблема конкретной реализации хранилища и существует много способов решения проблемы. которые от thin provisioning не зависят.
Когда ререзв становится меньше порога, начинать шейпить того клиента, потребление которого грозит исчерпать резевр быстрее, чем сделается апгрейд. Если он не один, то шейпить всех, у кого потребление превышает «нормальное». Соседи не страдают вообще. А тот или те, кто стали вдруг очень много писать, замедлятся, чтобы для них успели нарастить хранилище.
Если ситуация, когда нужно шейпить и апгрейдить, случается часто, это означает одну хорошую вещь и одноу плохую. Хорошая — продажа услуги быстро растет. Плохая — тот, кто планирует резерв, неоправданно его жмотит. Когда клиенты каждую субботу сжирают по 2 Тб за три часа, глупо держать резевр 2 Тб. Можете воспользоваться самостоятельно той формулой, для расчета запаса, которую я уже давал — добавьте в нее еще эти 2 Тб в неделю.
Для этого всего нужен QoS или просто шейпинг. Но если у вас шейпинг невозможно или трудно реализовать, то это не проблема thin provisioning как модели, а проблемы вашей конкретной реализации хранилища.
Про 20 Тб — это просто так за число зацепился. Порог и прочее по задаче можно точнее считать. Например, если вы уже знаете, что средняя скорость роста объема данных для вас за последний месяц составила 100 Гб в день, время добавления в СХД новых 10 Тб составляет 7 дней, то запас свободного места должен быть достаточным для того, чтобы без спешки успеть провести апгрейд и учетом рисков поставки оборудования невовремя или задержек по другим причинам. Скажем, считать что на апгрейд требуется 20 дней. Тогда порог срабатывания должен быть 2 Тб остатка. Схема общая, ее можно еще в зависимости от условий усложнять.
Блокируйте или ставьте шейпер на проблемного клиента в тот момент, когда срабатывает порог минимального запаса, 10%-20%. Как определить, кто проблемный? Элементарно. Тот, кто при экстраполяции потребления исчерпает ресурс быстрее, чем будет возможно его нарастить. Если лень с математикой заморачиваться, просто считать проблеными лидеров по росту потребления диска за последний день.
Если хотите показать недостатки thin provisioning, давайте, поспорьте с этим вариантом. Не нужно залезать на посторонние шкафы и спорить с тем, что будет видно с них.
Я указал уже три рабочих варианта, а вы — «не может быть решена». И упорно гнобите thin provisioning вообще, в то время как ограничение касается только выбранной вами реализации.
Понятно, что если какую-то функцию не хочется реализовывать или просто сложно, то можно найти сотню других причин, объясняющих, почему это не надо делать. Возводить при этом напраслину на технологии — это какая-то мелкая подлость. Достаточно сказать, экономический эффект не ясен — бюджет на такую переделку не предусмотрен.
Кстати, специальной файловой системой заниматься смысла тоже не больше. Она может быть и переживет невыделение места, а mysqld при проблеме записи может падать точно также аварийно.
Только, пожалуйста, не нужно привлекать к ответственности ни в чем не повинную модель thin provisioning. Она на то и модель, концепция одного аспекта организации хранилища, и не создает технических ограничений.
То, что XCP не дает готового механизма защиты от переполнения при коммите в TP, не означает того, что это технически невозможно. Вполне себе заурядная задача по допиливанию.
Если не случилось додумать решение, объясню подробнее:
Скажем, есть N клиентов, есть запас 20 Тб. Один клиент стал писать чудесным образом 500 Мб/сек и за 3 часа записал 5 Тб, свободных осталось 15 Тб.
Умные скрипты мониторинга видят, что дело грозит бедой и начинают ограничивать запись того одного, кто пишет так много. Можно самым простым способом — давать ему ошибку на запись, можно чуть сложнее — поставить для него шейпер записи на 1 Мбайт/сек. Можно еще проще — шейпить по скорости записи всех, но так лучше не делать.
1) В итоге от 90% клиентов, пострадавших от thin provisioning, разговор пришел к одному пострадавшему, которому может не получится записать 20 Тб за пол-дня.
2) Главным препятствием реализации биллинга по потреблению диска является забота об этом гипотетическом клиенте, то, что у вас для него нет красивого решения.
3) Претензий к схеме thin provisioning самой по себе нет.
Так?
Достаточно было сразу честно сказать, что из-за особенностей вашей дисковой системы это трудно или невозможно реализовать, а не придумывать мифические недостатки thin provisioning. У которой есть, разумеется, свои минусы, но совсем не те, о которых вы сейчас говорите.
Желающему записать 20 Тб при скорости 100 Мбайт/сек понадобится больше двух суток. То, что при этом у всех его соседей будет ощутимо тормозить диск и уже это будет деградацией сервиса, другой вопрос.
Но зачем вы решили, что при коммите одного обязательно должны пострадать все? Ограничьте только клиента, который вдруг решил исчерпать хранилище. Скажите ему заранее, еще задолго до того, как все заполнится, что все, не можете дать больше. Ведь если он памяти сотню гигов запросит, то же самое ему скажете.
По какой схеме это делать, можете и сами додумать.
Если вы не будете следить за сетью и потери доползут до 20%, это будет «всё» с большой буквы — отказ. Если будете недодавать памяти, то наступившие у клиентов убийства процессов из-за Out of Memory могут безвозвратно порушить данные. Если у клиента посещаемость вырастет в 10 раз, а вы ему не дадите процессора, это отнюдь не будет терпимо, его машина просто ляжет. А при невозможности записи на диск при журналируемой FS с работающими барьерами, авария будет ничуть не серьезнее.
Для дисков достаточно считать деградацией, требующей наращивания ресурсов, понижение свободного пространства, до, скажем, 20% с расстрелом допустившего понижение до 5%.