Простите за некрокоммент, но радуйтесь, что у Вас ничего не вышло с GFS2. Эксплуатировал принесённый интегратором криво настроенный GFS2 поверх FC (как ФС, без clvm) для хранения дисков ВМ — боль и страдания. Выкинул и вздохнул свободно. У того же Cinder (по крайней мере на начало 2015 года) довольно сносные драйверы для нарезания LUN-ов в СХД напрямую, можно было попробовать их (если у Вас, конечно, не MSA, драйвер к которому в ту пору то торжественно выкидывался из Cinder, то торжественно вносился обратно). Да и работой multipath в Ubuntu я не очень доволен (фантомные боли при «моргании» путями). В общем, у меня сложилось мнение, что с FC и прочим энтерпрайзом RHEL и его производные дружат значительно лучше просто на том основании, что в Ubuntu это никому не нужно.
В заголовке «сравниваем Moodle и Teachbase», в тексте же «с Moodle мы себя сравнивать не будем – это не вполне корректно». Что же не вполне кооректно: статья или заголовок?
Профессиональная поддержка у Moodle есть, на moodle.com/partners можно выбрать себе поддерживающего по вкусу (правда, когда я был в теме, в РФ было несколько больше зарегистрированных партнёров).
Что же до энтерпрайза — он тоже пользуется Moodle, ровно так же покупает систему с саппортом у партнёра и ещё пачку доработок для интеграции со своими остальными ИТ-системами (мы же про энтерпрайз говорим), как если бы это был продукт с закрытым исходным кодом. OpenSource != бесплатно, у каждого продукта есть стоимоть эксплуатации.
Преподавателю, который только создаёт курсы, а не устанавливает сам Moodle, знать веб-разработку необязательно, а если так хочется неспециалисту в ИТ свой Moodle заиметь — к его услугам разнообразные Moodle хостинги.
я всегда даю ему ID этого багрепорта из нашего внутреннего багтрекера
Я пил неделю (от радости), когда, скажем так, это появилось. Нельзя оставлять клиента с фразой «спасибо за ваше сообщение, это явно баг[, но даже если мы его починим, вы ни за что об этом не узнаете]».
Описание «OpenStack вкратце» местами способно ввести в заблуждение. Keystone практически не занимается авторизацией, и уж тем более не компонентов, а Nova не provision-ит виртуалки самостоятельно. Juno уже вышел, кстати, а Ironic перенесли на Kilo.
OpenStack это конструктор, интерфейс над существущими технологиями виртуализации, хранения данных, предоставления доступа в сеть. Просто так сложилось, что его чаще всего используют в связке KVM + Open vSwitch. API, на мой вкус, довольно кривое, чего стоит одна эпопея с «project» vs «tenant» в терминологии.
Надеяться, что конструктор сам (ну или по щучьему веленью) соберётся в нужную конфигурацию и будет работать, несколько наивно, и советую три раза подумать (и семь раз протестировать), прежде чем разворачивать сие в бой. Теги в посте проставлены правильно.
Из одного из postmortem-ов Amazon (раздел «EBS Software Bug Impacting Snapshots») косвенно следует, что снимки и тома физически удаляются не сразу. Теоретически можно (было) вступить в полемику с поддержкой и добиться от них чего-то на эту тему. Однако, после аналогичного сбоя задав вопрос «окей, вы сделали мне снимок тома, в котором нечитаемые области заполнены нулями; не поделитесь ли смещениями этих утерянных областей?», вразумительного ответа я так и не получил. Благо, спрашивал из чистого интереса и проще оказалось выкинуть том и сделать на его месте новый (все крупные «вылеты» AWS мы переживали очень удачно).
Люди en masse не умеют делать надёжные бекапы, потому что для этого надо быть пессимистом, параноиком и обладать способностью объяснить бизнесу «зачем нам ещё одна копия наших 10Т данных, за которые мы и так платим $1000 в месяц за хранилище и столько же за снимки?». Ну и популярный ныне «release early» — он про фичи, а не про надёжность. Фичу продать легко, а надёжность сложно, потому что люди очень везучи ровно до тех пор, пока они не станут невезучими.
Совет 0. Ваш sh-скрипт должен занимать максимум 2-4 экрана в редакторе. Если скрипт слишком большой — перепишите его на нормальном языке программирования. Perl и Python сейчас есть практически везде (embedded-гусары, молчать!).
Если Вы не можете написать простой и лаконичный скрипт, то это не скрипт. Либо напишите его и никому не показывайте (.bashrc — отличное место, где можно делать всё, что Вам угодно).
Противники этого совета могут попробовать взять на поддержку пачку унаследованных связанных друг с другом sh-скриптов хотя бы в 2 тысячи строк размером и 5 лет возрастом и поделиться ощущениями.
Явный кеш БД, вроде как, оторвали в 2.x, мотивируя это «лучшим» DB слоем? Хранить сессии в базе они сами не рекомендуют в вики (да и их сессии намного дешевле хранить на ФС с каким-либо session stickness в кластере). Запросов на чтение из БД в Moodle в разы (если не на порядки) больше, чем на запись, и в недрах трекера даже есть упоминание, венчающееся «мы что-то где-то как-то протестировали, нам не понравилось».
Я же тоже не просто так написал, я со всем этим реально сталкивался. И те 2.5 Moodle Partner'а, которых я своими глазами видел, либо гасят проблему производительности железом (иногда очень смешно), либо своими собственными разработчиками, которые делают как надо, а не как придётся. Есть, например, забавный тикет, в котором человек спрашивает разработчиков, зачем они раздачу статики от тем оформления запихали в PHP-скрипты. Доводы даже как-то местами понятны, и понятно, что это обходится поставленным впереди прокси-сервером, но ведь это знать надо, что оно вот так-то устроено и вот так-то без последствий лечится.
В своё время я правки в ядро просто по diff-ам от оригинальной версии посмотрел. Но мне было проще — была задача просто определить, можно ли это всё выкинуть без значительного ущерба для функционала.
> Moodle хорош именно как интеграционная платформа: достаточно стабилен, если не ставить экспериментальные версии (больше 60 тысяч инсталляций выявляют большинство проблем раньше, чем вы их заметите), масштабируем (имеются инсталляции более чем с 1 миллионом пользователей)
Всё бы хорошо, но есть нюансы. Выявить-то большинство проблем выявят, но вот когда разработчики их починят — большой вопрос.
Масштабирование «из коробки» практически никакое: нет поддержки read-only slave DB (хотя обещают), нет поддержки X-Sendfile (хотя обещают), по некоторым тикетам напрашивается вывод, что собственно разработчики Moodle нагрузочным тестированием себя не утруждают. На одном и том же сервере инсталляция версии 2.0 по умолчанию ест вдвое больше ресурсов (по времени генерации страницы/данным performance info), чем инсталляция по умолчанию 1.9.
По коду разбросано вдохновляющее количество хардкода (например, максимальное количество недель в курсе и combobox для него на 52 элемента вместо textbox'а с одним числом, период enrollment'а).
В итоге, для реализация масштаба ВУЗа не соглашусь с автором в части «никаких правок в ядре, никаких патчей и хаков». Да, нужно постараться максимально их избежать, но делать их всё равно придётся рано или поздно, ибо некоторые вещи через API недоступны. Так что лучше сразу обеспечить наличие под рукой хоть какого-то специалиста в PHP, который умеет вести документацию на доработки и таскать их от релиза к релизу.
Ну и да, не стоит мне писать, что это OSS, где твой вклад и т.д., ибо я не разработчик. В конце концов, я же не говорю, что хуже Moodle нет, а лишь сожалею, что нет сильно лучше.
Мне тоже не хватало маленьких 64-бит инстансов, ибо теперь не нужно держать по две AMI в регионе для разных размеров инстансов, достаточно только одной. И смена размера инстанса на любой теперь производится простым остановом/запуском — удобно.
К тому же, появилась закрывашка для дырки в оперативной памяти инстанса (1Гбайт — 2Гбайт — дырка — 8Гбайт).
Внутри AZ можно отцеплять/прицеплять диски. Внутри региона между разными AZ — через снимок тома. Между регионами — только посредством третьих инструментов типа rsync.
Одно дело, когда один человек роет себе одну яму ровно с человека размером. Другое — когда десятки тысяч людей роют котлован, в который попадают вообще все.
Да, membership agreement не позволяет клиенту передавать его учётные данные третьм лицам, иначе books24x7 осталяет за собой право прекратить доступ без возврата денег. Также там оговаривается запрет на зеркалирование книг с помощью софта а-ля Teleport Pro и правила по использованиюскачиваемого контента. На сайте можно целиком прочитать.
Профессиональная поддержка у Moodle есть, на moodle.com/partners можно выбрать себе поддерживающего по вкусу (правда, когда я был в теме, в РФ было несколько больше зарегистрированных партнёров).
Что же до энтерпрайза — он тоже пользуется Moodle, ровно так же покупает систему с саппортом у партнёра и ещё пачку доработок для интеграции со своими остальными ИТ-системами (мы же про энтерпрайз говорим), как если бы это был продукт с закрытым исходным кодом. OpenSource != бесплатно, у каждого продукта есть стоимоть эксплуатации.
Преподавателю, который только создаёт курсы, а не устанавливает сам Moodle, знать веб-разработку необязательно, а если так хочется неспециалисту в ИТ свой Moodle заиметь — к его услугам разнообразные Moodle хостинги.
Я пил неделю (от радости), когда, скажем так, это появилось. Нельзя оставлять клиента с фразой «спасибо за ваше сообщение, это явно баг[, но даже если мы его починим, вы ни за что об этом не узнаете]».
Потом всевластный root в скрипте по крону пишет:
И в итоге некоторые файлы не то, чтобы совсем не удаляются, но удаляются не те, что нужно.
Место для хождения по граблям в статье выделено совершенно правильно, да и аргументом xargs может быть не только rm.
OpenStack это конструктор, интерфейс над существущими технологиями виртуализации, хранения данных, предоставления доступа в сеть. Просто так сложилось, что его чаще всего используют в связке KVM + Open vSwitch. API, на мой вкус, довольно кривое, чего стоит одна эпопея с «project» vs «tenant» в терминологии.
Надеяться, что конструктор сам (ну или по щучьему веленью) соберётся в нужную конфигурацию и будет работать, несколько наивно, и советую три раза подумать (и семь раз протестировать), прежде чем разворачивать сие в бой. Теги в посте проставлены правильно.
Люди en masse не умеют делать надёжные бекапы, потому что для этого надо быть пессимистом, параноиком и обладать способностью объяснить бизнесу «зачем нам ещё одна копия наших 10Т данных, за которые мы и так платим $1000 в месяц за хранилище и столько же за снимки?». Ну и популярный ныне «release early» — он про фичи, а не про надёжность. Фичу продать легко, а надёжность сложно, потому что люди очень везучи ровно до тех пор, пока они не станут невезучими.
Я уж думал, что не доживу.
Если Вы не можете написать простой и лаконичный скрипт, то это не скрипт. Либо напишите его и никому не показывайте (.bashrc — отличное место, где можно делать всё, что Вам угодно).
Противники этого совета могут попробовать взять на поддержку пачку унаследованных связанных друг с другом sh-скриптов хотя бы в 2 тысячи строк размером и 5 лет возрастом и поделиться ощущениями.
Однако, для тысяч серверов приведённое решение мне кажется более подходящим хотя бы потому, что вся аутентификация/авторизация происходит локально.
Я же тоже не просто так написал, я со всем этим реально сталкивался. И те 2.5 Moodle Partner'а, которых я своими глазами видел, либо гасят проблему производительности железом (иногда очень смешно), либо своими собственными разработчиками, которые делают как надо, а не как придётся. Есть, например, забавный тикет, в котором человек спрашивает разработчиков, зачем они раздачу статики от тем оформления запихали в PHP-скрипты. Доводы даже как-то местами понятны, и понятно, что это обходится поставленным впереди прокси-сервером, но ведь это знать надо, что оно вот так-то устроено и вот так-то без последствий лечится.
В своё время я правки в ядро просто по diff-ам от оригинальной версии посмотрел. Но мне было проще — была задача просто определить, можно ли это всё выкинуть без значительного ущерба для функционала.
Всё бы хорошо, но есть нюансы. Выявить-то большинство проблем выявят, но вот когда разработчики их починят — большой вопрос.
Масштабирование «из коробки» практически никакое: нет поддержки read-only slave DB (хотя обещают), нет поддержки X-Sendfile (хотя обещают), по некоторым тикетам напрашивается вывод, что собственно разработчики Moodle нагрузочным тестированием себя не утруждают. На одном и том же сервере инсталляция версии 2.0 по умолчанию ест вдвое больше ресурсов (по времени генерации страницы/данным performance info), чем инсталляция по умолчанию 1.9.
По коду разбросано вдохновляющее количество хардкода (например, максимальное количество недель в курсе и combobox для него на 52 элемента вместо textbox'а с одним числом, период enrollment'а).
В итоге, для реализация масштаба ВУЗа не соглашусь с автором в части «никаких правок в ядре, никаких патчей и хаков». Да, нужно постараться максимально их избежать, но делать их всё равно придётся рано или поздно, ибо некоторые вещи через API недоступны. Так что лучше сразу обеспечить наличие под рукой хоть какого-то специалиста в PHP, который умеет вести документацию на доработки и таскать их от релиза к релизу.
Ну и да, не стоит мне писать, что это OSS, где твой вклад и т.д., ибо я не разработчик. В конце концов, я же не говорю, что хуже Moodle нет, а лишь сожалею, что нет сильно лучше.
К тому же, появилась закрывашка для дырки в оперативной памяти инстанса (1Гбайт — 2Гбайт — дырка — 8Гбайт).