Pull to refresh

Comments 8

Встроенный мониторинг

Они всё-таки допилили полноценный мониторинг или так и остался тот кастрат, с глючными графиками? :)
Может и допилили, но для меня любой встроенный мониторинг обычно так и выглядит. :) На самом деле, ситуация близка к отраслевому стандарту, мониторинг есть, но для галочки. Мы используем свой отдельный мониторинг.
А почему не вижу в списке вариантов, которые были, openstack swift? На сколько помню у него есть адаптер S3. Может он и не все поддерживает, но кто мешает добавить?:)
Спасибо за вопрос!
Честно говоря на свифт не смотрели по ряду причин, а так мы относимся к инфраструктурным провайдерам, а не к разработчикам ПО. У нас что-то такое допиливать нет ни возможности, ни желания.

Гартнер ранее говорил о проблемах производительности nas надстройки и далекой от 100 процентах совместимости api, тк новые фишки в родном s3 появляются ранее. Так ли это все?


В родном s3 обьекты обьемом менее 128кб округляются вроде биллингом до 128, тут так же?


Вроде в консоли есть возможность задать secondary/backup puppet master узел, в случае сбоя он корректно не переключается сам?


Раскидывая новые узлы по новым рекам, rack awareness корректно работает при достаточном числе узлов?


Расскажите как реализованы white list на сетевом уровне, чтобы трафик не тарифицировался, если например работа в рамках ЦОДа, а не по интернету.

Спасибо за вопросы!

«Гартнер ранее говорил о проблемах производительности nas надстройки и далекой от 100 процентах совместимости api, тк новые фишки в родном s3 появляются ранее. Так ли это все?» NAS надстройка действительно тормозит, мы её поэтому и не используем. Совместимость реализуется действительно по догоняющему принципу, иначе никак. Но реализуется. Задержка конечно есть, складывается из реакции Cloudian и потом нашего обновления. Но она и в SDK будет.

«В родном s3 обьекты обьемом менее 128кб округляются вроде биллингом до 128, тут так же?» Нет, тут округляется до килобайта т.е. по сути не округляется. То же касается и стоимости запросов — 10001 запрос это именно 10001 запрос.

«Вроде в консоли есть возможность задать secondary/backup puppet master узел, в случае сбоя он корректно не переключается сам?» Конфигурация от Cloudian предполагает ручное переключение. Собственно все это счастье поставляется одним большим бинарём-инсталятором и дальше оно само разворачивает через мастер. Мы руками в конфигурации, в таких ситуациях, без критической необходимости не лазаем, что бы не отхватывать проблем лишних при обновлениях.

«Раскидывая новые узлы по новым рекам, rack awareness корректно работает при достаточном числе узлов?» Такого эксперимента не проводили, у нас же всего 4 ноды. Такую конфигурацию тащить на несколько стоек большого смысла нет.

«Расскажите как реализованы white list на сетевом уровне, чтобы трафик не тарифицировался, если например работа в рамках ЦОДа, а не по интернету.» Мы не сетевым оборудованием его биллим, а встроенным в Cloudian биллингом. Там есть возможность привязать white list к конкретному тарифному плану. Собственно по просьбе клиента мы можем это организовать, если используется выделенный под клиента линк до хранилища.

Касательно white-list скорее был вопрос про организацию. Для работы того же https s3 должно корректно резолвить имя, проверить сертификат. В случае работы не по интернету подымаются какие-то свои приватные dns? На балансерах вешается влан/адрес приватной сети для заказчика каждого или выделено что-то вроде общего dmz, откуда отдельным заказчикам выделяются адреса, а дальше l3 в их сети?

Вайтлист работает по исходящим IP адресам. Мы пробрасываем серую сетку в l3 от клиента до нас и ее адреса добавляем вайтлист. Кстати, об этом будет в следующей статье :)
Sign up to leave a comment.