Отдельная благодарность автору за пьесу в баре, довольно жизненно, хотя встречаются ситуации в текущем IT рынке и похуже. Очень понравилась мысль про "выученную беспомощность", которая во многих командах действительно является проблемой, когда один выученно не хочет думать, а другой просто этого не умеет, а потом вместо рабочего продукта на выходе получается сами знаете что.
А в целом хорошо что нашли рабочую схему для себя и она у вас работает, главное чтобы она не порушилась с приходом какого-то либо нового "эффективного менеджера" в бизнес или куда либо ещё.
1. Да, пожалуй на отказоустойчивость heketi можно забить, т.к. если PVC был создан, то при последующем запуске пода heketi не нужен. Но, если вы внимательно читали пост, а не мимо строк дабы высказать свое мнение, то вы наверняка заметили, что основной проблемой является mount через gluster, которого у нас нет, как и нет возможности его нормально поставить. Вариант в Endpoint наиболее удобный, если нет нужды динамического создания Volume, и я могу сказать, что довольно часто это не нужно. Таким образом человек, который будет это использовать, избавится от кучи лишних прослоек и будет сам управлять своим стораджем. Я не говорю что heketi — то хорошо или плохо, но я считаю что вполне можно обойтись и без него.
2. Разумеется пробовал. И смысл того, что данный вариант не подходит в том, что база heketi должна быть на диске, а значит либо городить еще одно хранилище, или держать его на одной ноде (возможно в рамках одного ДЦ) и это не дает нужной отказоустойчивости. Плюс, хочу заметить, что я не писал что это не возможно, мысль скорее в том, что смысла тащить в кубер его нет.
3. Так отрабатывает таймаут у маунта. Минутный простой в случае падения одной из нод — это не критично. Как я уже говорил, это далеко не эталонное решение, но кто столкнется с проблемой, может использовать и его.
4. Не так как ожидалось, но цель достигнута.
Еще раз повторюсь, я не утверждаю что это правильно и надо так делать, кому нужно будет, может использовать, кому нет, тот может основываясь на статье принять решение о том, стоит ли им этим заниматься.
Много систем отпадало по причине недостаточной документации или избыточности, как Ceph.
Сравнение делалось только с Ceph, который разумеется, производительнее, но и значительно сложнее.
Такую FS даже не встречал. Жаль, что не написали пост о ней, было бы интересно ознакомиться. Но к малоизвестным системам тяги нет, в случае нештатных ситуаций легко можно оказаться без помощи или ждать исправления проблемы долгое время, а в случае FS еще и потерять данные.
Разумеется, возможно использовать репликацию данных и другими способами, сверху обвесив тем же NFS и keepalived и получить по сути аналогичную систему. Но сейчас очень пользуется популярностью GlusterFS и предлагает легкое развертывание в режиме мультимастеров и простую поддержку, поэтому надо было испробовать данное решение на совместимость, а то, с чем мы столкнулись описано выше. Конечная схема с велосипедами — не идеальное решение, но большая часть людей остановится на варианте работы с гластером через их протокол и в данных велосипедах не будут нуждаться, ну, а если нет, то любые средства хороши, главное получить желаемый результат.
Отдельная благодарность автору за пьесу в баре, довольно жизненно, хотя встречаются ситуации в текущем IT рынке и похуже. Очень понравилась мысль про "выученную беспомощность", которая во многих командах действительно является проблемой, когда один выученно не хочет думать, а другой просто этого не умеет, а потом вместо рабочего продукта на выходе получается сами знаете что.
А в целом хорошо что нашли рабочую схему для себя и она у вас работает, главное чтобы она не порушилась с приходом какого-то либо нового "эффективного менеджера" в бизнес или куда либо ещё.
2. Разумеется пробовал. И смысл того, что данный вариант не подходит в том, что база heketi должна быть на диске, а значит либо городить еще одно хранилище, или держать его на одной ноде (возможно в рамках одного ДЦ) и это не дает нужной отказоустойчивости. Плюс, хочу заметить, что я не писал что это не возможно, мысль скорее в том, что смысла тащить в кубер его нет.
3. Так отрабатывает таймаут у маунта. Минутный простой в случае падения одной из нод — это не критично. Как я уже говорил, это далеко не эталонное решение, но кто столкнется с проблемой, может использовать и его.
4. Не так как ожидалось, но цель достигнута.
Еще раз повторюсь, я не утверждаю что это правильно и надо так делать, кому нужно будет, может использовать, кому нет, тот может основываясь на статье принять решение о том, стоит ли им этим заниматься.
Сравнение делалось только с Ceph, который разумеется, производительнее, но и значительно сложнее.
Такую FS даже не встречал. Жаль, что не написали пост о ней, было бы интересно ознакомиться. Но к малоизвестным системам тяги нет, в случае нештатных ситуаций легко можно оказаться без помощи или ждать исправления проблемы долгое время, а в случае FS еще и потерять данные.