Здравствуйте! Спасибо за поздравления! По поводу вопросов:
В версии 19.2.2 есть ряд полезных фичей в части S3, и одновременно с этим лучше производительность OSD. Когда-нибудь, возможно, сделаем материал про то, как мы бенчмаркаем кластеры.
Мигрировали по-разному :) Например, переносом пула между device class'ами, без смены EC-профиля, или через cache tiering — иначе нельзя перенести данные в пулы с разным EC-профилем.
Разделяем вланами, не боимся — LACP все стерпит, .1p всех сравняет.
Это зависит от (размера) кластера, количества фейлюр доменов. Обычно мы выставляем m=2 для обеспечения возможности потери двух доменов отказа + оставляем всегда запас по оборудованию, как минимум в один домен отказа, чтобы при утрате домена отказа было куда мигрировать данные. В итоге для нас типичные конфигурации это X+2, где X может быть 6, 8, 10, 12 и так далее.
Самый главный фактор — в мире существует крайне ограниченное количество производителей, которые делают SATA SSD грейда дата-центров объемом более 8 TБ и никто из них не представлен на российском рынке. Ну а менее 8 TБ уменьшают плотность, не давая по сути никаких плюсов при больших объемах (но если объем кластера небольшой, а нагрузка большая — это может, конечно же, иметь смысл).
SLA считаем на основе опыта эксплуатации всех облачных продуктов. Достигается за счет сочетания отказоустойчивой архитектуры, мониторинга, резервирования и быстрого реагирования, а расчет проводится на основе точного учета времени доступности сервиса.
Мы сравнивали с классическими подходами, используемыми в связке с OpenStack — ML2/OVS и Linux bridges. Dragonflow, OpenDaylight не рассматривали, поскольку либо неактуально, либо требуется несопоставимо больше усилий по интеграции и сопровождению. OVN оказался для нас наиболее рациональным и практичным выбором.
Будет интересно узнать про ваш опыт с OVN, когда попробуете.
Мы выбрали OVN, потому что он проще в использовании, надёжнее и лучше интегрирован в OpenStack. Это нативное решение от разработчиков Open vSwitch (OVS), что обеспечивает тесную интеграцию и предсказуемую работу с виртуальной сетевой инфраструктурой. У OVN есть довольно живое российское коммьюнити, что упрощает поиск решений и обмен опытом.
OpenSDN рассматривался как потенциальный вариант, но до этапа тестирования не дошёл. Мы пришли к выводу, что он избыточен и слишком сложен для наших задач. Особенно стоит отметить высокий порог вхождения, что делает его менее подходящим для небольших команд с ограниченными ресурсами.
Инструменты автоматизации и воспроизводимости мы, конечно, используем. Существует отдельная статья, где мы про это уже рассказывали (про rook там тоже есть). Но сейчас мы несколько о другом.
Привет! Согласны, что накрутки опыта — токсичная практика, которая не приведёт ни отрасль, ни рынок труда ни к чему хорошему. К сожалению, полностью искоренить это явление невозможно, но считаем, что ситуацию можно улучшить, если каждый (имеем в виду: как соискатель, так и компании) начнёт с себя.
Вот что делаем мы: не пользуемся автоматическими фильтрами, а читаем резюме кандидата и опираемся на его опыт и навык владения технологиями на всех этапах собеседования. Как правило, в наших вакансиях вакансиях указывается грейд, который выражается в годах работы и четко прописанных технологиях, необходимых под проект/вакансию. Ещё мы ценим откровенность и не видим ничего страшного, если кандидат покажет свои слабые места — тогда диалог будет строиться более прозрачно. И, если у команды действительно есть возможность на данном этапе пожертвовать неким опытом, которого у соискателя пока нет — они смогут поделиться им уже после выхода кандидата на вакансию. А вот обман со стороны кандидата, который (если имел место) с высочайшей вероятностью вскрывается на поздних этапах собеседования — однозначно красный флаг.
Понимаем ваши вопросы :) Со своей стороны хотели скорее поделиться, что в принципе есть такое исследование: нам тут показались интересными именно подход и ориентация на ширину возможностей. Видимо, теперь будем всем Хабром писать вопросы в Южную Корею!
Жаль, что эта статья оставила такое впечатление. Мы хотели приоткрыть завесу тайны, почему интервьюеры задают такие вопросы, какие они задают, и на что смотрят, и, естественно, наши слова не нужно вырывать из контекста :)
Но давайте по порядку:
Если у нас есть подозрение, что собеседник по какой-то причине оказался не готов к интервью, устал, его что-то отвлекает или просто на улице жара, мы просто спросим его об этом и предложим перенести встречу. Это нормально и все мы люди, все мы устаем, погода от нас не зависит, и все мы это понимаем. Камера помогает получить предпосылки.
Мы не утверждаем, что наши методы уникальные или даже универсальные, мы рассказываем, как мы проводим интервью. Они могут подходить не всем.
Для нас есть разница между «гореть своим делом и хотеть деньги за свою работу» и «хотеть денег и выполнять функцию» — там речь именно про эту разницу. Мы тщательно следим за ростом наших коллег и стараемся их в этом поддерживать, делать процесс этого роста прозрачнее, как с точки зрения их навыков, так и с точки зрения компенсации их труда, так что бесплатно работать не нужно — это плохая практика :)
Ключевая цель любого интервью — диалог. Если мы его можем установить — это хорошо, если нет (и это не видится возможным), возможно, мы просто не та команда для конкретного претендента. В любом случае, если вы подходите для наших вакансий — можете попробовать пройти собеседование и сравнить реальность и ожидания :)
Мы не ставили задачей раскрыть тему о тестировании производительности разных видеокарт. Мы рассказываем про путь бизнеса по направлению оптимизации рабочих процессов с помощью ИИ.
Конечно можно) Часть заказанного оборудования не приехала к моменту старта стройки, пришлось использовать резервы и строить ядро не на том, на чем планировалось изначально. Переезд нам тут даже только помог — привели площадку в соответствие стандарту, который выработали позднее, больше от него отходить не будем. Увеличили срок от планирования до реализации. Теперь на подобные проекты оборудование мы закупаем минимум за полгода. Создали отдельную команду по запуску локации из высококвалифицированных инженеров. Они же и принимают ту работу по площадке, которая была сделана в их отсутствие (если таковая возникает дополнительно). Обязателен 10% запас по всем проводам, патчкордам и AOC-ам. Бывает брак, бывает не доложат в закупку, бывает сами сломали. Органайзеры — обязательно. AOC и DAC-и — определенной длины. Всё собираем в косы. Обязательные маркировки межстойки. Обязательные углы, зазоры для простого обслуживания/замены.
1) Вы правы, тут подразумевается "оценить качество тестирования ПО"
2) И здесь тоже "общее качество тестирования"
3) У нас нет привязки багов к фичам или конкретным релизам, поэтому учитываются все баги, которые не дошли до пользователя
4) Тут работает негласное правило - если баг появился в результате выкатки новой фичи (неважно, в существующем ранее коде или в новом), то считаем, что это "Баг после релиза"
Вы правы, дублирование далеко не всегда означает надежность. В статье мы рассказали о резервировании сетевой части и управляющей части кластера прежде всего на физическом уровне. Исходя из нашего опыта, риск отказа (недоступность сервисов) значительно уменьшается в случае использования резервных операторов связи, основных сетевых компонентов схемы — от TOR-свитчей до патч-кордов, которые случайно может задеть сотрудник ЦОД при работах. А использование распределенного кластера управления облаком позволяет не зависеть от сбоев работы конкретного сервера и проводить периодическое обслуживание оборудования.
Добрый день. Порядок разрешения споров описан в оферте, она есть на сайте SpaceWeb. Если у вас уже возникли какие-то сложности, напишите нам, пожалуйста, в техподдержку.
Добрый день. Видим, что работы по устранению проблемы в рамках обращения 20240526373010136 ведутся, и решению уделено особое внимание.
Альтернативный вариант решения проблемы коллеги предложили в рамках заявки 20240528373007949. Приносим искренние извинения за доставленные неудобства. ?
Здравствуйте! Спасибо за поздравления! По поводу вопросов:
В версии 19.2.2 есть ряд полезных фичей в части S3, и одновременно с этим лучше производительность OSD. Когда-нибудь, возможно, сделаем материал про то, как мы бенчмаркаем кластеры.
Мигрировали по-разному :) Например, переносом пула между device class'ами, без смены EC-профиля, или через cache tiering — иначе нельзя перенести данные в пулы с разным EC-профилем.
Разделяем вланами, не боимся — LACP все стерпит, .1p всех сравняет.
Это зависит от (размера) кластера, количества фейлюр доменов. Обычно мы выставляем m=2 для обеспечения возможности потери двух доменов отказа + оставляем всегда запас по оборудованию, как минимум в один домен отказа, чтобы при утрате домена отказа было куда мигрировать данные. В итоге для нас типичные конфигурации это X+2, где X может быть 6, 8, 10, 12 и так далее.
Самый главный фактор — в мире существует крайне ограниченное количество производителей, которые делают SATA SSD грейда дата-центров объемом более 8 TБ и никто из них не представлен на российском рынке. Ну а менее 8 TБ уменьшают плотность, не давая по сути никаких плюсов при больших объемах (но если объем кластера небольшой, а нагрузка большая — это может, конечно же, иметь смысл).
SLA считаем на основе опыта эксплуатации всех облачных продуктов. Достигается за счет сочетания отказоустойчивой архитектуры, мониторинга, резервирования и быстрого реагирования, а расчет проводится на основе точного учета времени доступности сервиса.
Мы сравнивали с классическими подходами, используемыми в связке с OpenStack — ML2/OVS и Linux bridges.
Dragonflow, OpenDaylight не рассматривали, поскольку либо неактуально, либо требуется несопоставимо больше усилий по интеграции и сопровождению.
OVN оказался для нас наиболее рациональным и практичным выбором.
Будет интересно узнать про ваш опыт с OVN, когда попробуете.
Мы выбрали OVN, потому что он проще в использовании, надёжнее и лучше интегрирован в OpenStack. Это нативное решение от разработчиков Open vSwitch (OVS), что обеспечивает тесную интеграцию и предсказуемую работу с виртуальной сетевой инфраструктурой.
У OVN есть довольно живое российское коммьюнити, что упрощает поиск решений и обмен опытом.
OpenSDN рассматривался как потенциальный вариант, но до этапа тестирования не дошёл. Мы пришли к выводу, что он избыточен и слишком сложен для наших задач. Особенно стоит отметить высокий порог вхождения, что делает его менее подходящим для небольших команд с ограниченными ресурсами.
Инструменты автоматизации и воспроизводимости мы, конечно, используем. Существует отдельная статья, где мы про это уже рассказывали (про rook там тоже есть). Но сейчас мы несколько о другом.
Nextcloud поддерживает внешние хранилища. Например, в этой инструкции мы рассказали как подключить S3: https://help.reg.ru/support/servery-vps/obyektnoye-khranilishche-s3/podklyuchenie-hranilisha-s3-k-nextcloud
Привет! Согласны, что накрутки опыта — токсичная практика, которая не приведёт ни отрасль, ни рынок труда ни к чему хорошему. К сожалению, полностью искоренить это явление невозможно, но считаем, что ситуацию можно улучшить, если каждый (имеем в виду: как соискатель, так и компании) начнёт с себя.
Вот что делаем мы: не пользуемся автоматическими фильтрами, а читаем резюме кандидата и опираемся на его опыт и навык владения технологиями на всех этапах собеседования. Как правило, в наших вакансиях вакансиях указывается грейд, который выражается в годах работы и четко прописанных технологиях, необходимых под проект/вакансию. Ещё мы ценим откровенность и не видим ничего страшного, если кандидат покажет свои слабые места — тогда диалог будет строиться более прозрачно. И, если у команды действительно есть возможность на данном этапе пожертвовать неким опытом, которого у соискателя пока нет — они смогут поделиться им уже после выхода кандидата на вакансию. А вот обман со стороны кандидата, который (если имел место) с высочайшей вероятностью вскрывается на поздних этапах собеседования — однозначно красный флаг.
Спасибо за отзыв, постараемся учесть это пожелание!
Понимаем ваши вопросы :) Со своей стороны хотели скорее поделиться, что в принципе есть такое исследование: нам тут показались интересными именно подход и ориентация на ширину возможностей. Видимо, теперь будем всем Хабром писать вопросы в Южную Корею!
Жаль, что эта статья оставила такое впечатление. Мы хотели приоткрыть завесу тайны, почему интервьюеры задают такие вопросы, какие они задают, и на что смотрят, и, естественно, наши слова не нужно вырывать из контекста :)
Но давайте по порядку:
Если у нас есть подозрение, что собеседник по какой-то причине оказался не готов к интервью, устал, его что-то отвлекает или просто на улице жара, мы просто спросим его об этом и предложим перенести встречу. Это нормально и все мы люди, все мы устаем, погода от нас не зависит, и все мы это понимаем. Камера помогает получить предпосылки.
Мы не утверждаем, что наши методы уникальные или даже универсальные, мы рассказываем, как мы проводим интервью. Они могут подходить не всем.
Для нас есть разница между «гореть своим делом и хотеть деньги за свою работу» и «хотеть денег и выполнять функцию» — там речь именно про эту разницу. Мы тщательно следим за ростом наших коллег и стараемся их в этом поддерживать, делать процесс этого роста прозрачнее, как с точки зрения их навыков, так и с точки зрения компенсации их труда, так что бесплатно работать не нужно — это плохая практика :)
Ключевая цель любого интервью — диалог. Если мы его можем установить — это хорошо, если нет (и это не видится возможным), возможно, мы просто не та команда для конкретного претендента. В любом случае, если вы подходите для наших вакансий — можете попробовать пройти собеседование и сравнить реальность и ожидания :)
Здравствуйте! А вы обращались в техподдержку с вашей проблемой?
В сравнении нет акцента на то, что какая-то система лучше или хуже, у всех них есть свои проблемы и свои достоинства.
Спасибо за уточнение, мы учтем этот момент и при необходимости спланируем переход на другую TMS, так как такой опыт есть в компании.
Мы не ставили задачей раскрыть тему о тестировании производительности разных видеокарт. Мы рассказываем про путь бизнеса по направлению оптимизации рабочих процессов с помощью ИИ.
Именно в облаке удалось так значительно ускорить время обучения ИИ, на локальном сервере этого не получалось.
Конечно можно) Часть заказанного оборудования не приехала к моменту старта стройки, пришлось использовать резервы и строить ядро не на том, на чем планировалось изначально. Переезд нам тут даже только помог — привели площадку в соответствие стандарту, который выработали позднее, больше от него отходить не будем.
Увеличили срок от планирования до реализации. Теперь на подобные проекты оборудование мы закупаем минимум за полгода.
Создали отдельную команду по запуску локации из высококвалифицированных инженеров. Они же и принимают ту работу по площадке, которая была сделана в их отсутствие (если таковая возникает дополнительно).
Обязателен 10% запас по всем проводам, патчкордам и AOC-ам. Бывает брак, бывает не доложат в закупку, бывает сами сломали.
Органайзеры — обязательно. AOC и DAC-и — определенной длины. Всё собираем в косы. Обязательные маркировки межстойки. Обязательные углы, зазоры для простого обслуживания/замены.
1) Вы правы, тут подразумевается "оценить качество тестирования ПО"
2) И здесь тоже "общее качество тестирования"
3) У нас нет привязки багов к фичам или конкретным релизам, поэтому учитываются все баги, которые не дошли до пользователя
4) Тут работает негласное правило - если баг появился в результате выкатки новой фичи (неважно, в существующем ранее коде или в новом), то считаем, что это "Баг после релиза"
Вы правы, дублирование далеко не всегда означает надежность. В статье мы рассказали о резервировании сетевой части и управляющей части кластера прежде всего на физическом уровне. Исходя из нашего опыта, риск отказа (недоступность сервисов) значительно уменьшается в случае использования резервных операторов связи, основных сетевых компонентов схемы — от TOR-свитчей до патч-кордов, которые случайно может задеть сотрудник ЦОД при работах. А использование распределенного кластера управления облаком позволяет не зависеть от сбоев работы конкретного сервера и проводить периодическое обслуживание оборудования.
Добрый день. Порядок разрешения споров описан в оферте, она есть на сайте SpaceWeb. Если у вас уже возникли какие-то сложности, напишите нам, пожалуйста, в техподдержку.
Добрый день! Документация пока готовится, статьи будут публиковаться здесь. А статью о внутреннем устройстве планируем скоро выложить на Хабр.
Добрый день.
Видим, что работы по устранению проблемы в рамках обращения 20240526373010136 ведутся, и решению уделено особое внимание.
Альтернативный вариант решения проблемы коллеги предложили в рамках заявки 20240528373007949. Приносим искренние извинения за доставленные неудобства. ?