Почти во всех случаях возникающие проблемы – это результат тех или иных ограничений. Например, в одном проекте, где мы упёрлись в потолок производительности, проблемой было ограниченное число выделяемых на сервис виртуальных машин. А у заказчика из поста выше есть ограничения не только на число ВМ (ограничение продиктовано стоимостью обладания каждой отдельной машиной), но и на возможности команд, которые будут отдавать свои данные. Проблема производительности на тестовой инсталляции не возникала, она обозначена исключительно как потенциальная. И для решения её предложен вариант близкий к тому, какой вы описываете: поднимать дополнительные logstash для натравливания на разные очереди.
Устанавливаем компоненты разными путями: всё зависит от ИТ-инфраструктуры и требований заказчика. Где-то всё ставится в Kubernetes/OpenShift, где-то компоненты распределяются частями: что-то в Kuber, что-то на виртуализации, бывает даже на железных серверах. Естественно, все процессы максимально автоматизируются плейбуками.
Мы рекомендуем начать с вашего окружения и где вы собираетесь разворачивать кластеры K8s.
Tanzu CE поддерживает несколько платформ – VMware vSphere, AWS, Azure и пока в экспериментальном режиме локальный docker. Tanzu CE не поможет, если вы хотите развернуть K8s на физических серверах.
Одно из основных преимуществ Tanzu CE – наличие экосистемы продуктов, которые можно доустанавливать с помощью пакетного менеджера и практически «из коробки» получить их интеграцию.
Можно начать с изучения документации: https://tanzucommunityedition.io/docs/latest/. Там же подробно описан процесс инсталляции, работы с пакетами, масштабирование кластеров и многое другое.
Задержки на локальную коммутацию внутри свича несущественны. Они составляют менее 1 микросекунды (не путать с миллисекундой — это в 1000 раз меньше). Для коммутаторов Gen 6 (32 Gb) локальные задержки составляют 780 наносекунд, для коммутаторов Gen 7 (64 Gb) — 460 наносекунд. Весь остальной стек Storage-SAN-Host в протестированных решениях обеспечил ввод/вывод через SAN с задержками порядка 100 микросекунд. А это, на наш взгляд, — отличный результат.
Картинка описывает соотношение уровня (порядка) производительности накопителей разного типа. У нас не было цели сравнивать производительность и задержки локального накопителя и накопителей в составе СХД. Речь про Enterprise и общий доступ к дисковым ресурсам с обеспечением отказо- и катастрофоустойчивости.
В СХД, кроме самих дисков, добавляется несколько уровней абстракции: протокол подключения дисков, организация пула хранения и протоколы доступа. На уровне подключения многие производители СХД уже давно используют NVMe. Пулы хранения производители СХД организуют по-разному: кто-то собирает классический RAID, кто-то собирает RAID на чанках, плюс дедупликация, плюс компрессия. На уровне протоколов блочного доступа стандартом де-факто стали FC и iSCSI. Сейчас это семейство пополнилось NVMe over Fabrics включая RoCE и NVMe over FC и возможными их инкапсуляциями. Акцент статьи именно на сравнении протоколов доступа SAN.
По поводу задержек. Производители СХД, чтобы снизить задержки, используют и кэширование, и тиринг. Вместе с современными протоколами доступа это позволяет получать задержки почти на порядок меньше 1 ms при подключении через SAN. Из инструментов для тестирования — vdbench.
Новые тесты и рассказ про методику в планах на будущее.
Я старался написать про инструменты которые не так известны и популярны как тот же TensorFlow и тем более Apache Airflow/Beam, которые используется не только в ML сфере (хотя в итоге упомянул еще и Jupyter, хоть и с другим посылом :D). В любом случае, инструменты, что вы упомянули определенно заслуживают внимания)
В комментах выше все по-разному оценивают ситуацию с ИТ в Австралии, и, конечно, везде есть свои плюсы и минусы. Но вот что важно, например, знать про ИТ там, чтобы оценивать: в Австралии интернет adsl 10 мегабит стоит 60 долларов в меcяц. Есть NBN, но он не намного дешевле и не намного лучше.
Я сменил направление, но с ИБ уже работал в Остине как инженер, там написано, что я внедрял, например, IDM. Плюс у меня достаточно инженерного опыта в иб было до. Но моя специализация всё-таки была инфраструктурной. Поэтому это смена области. Позиция архитектора не подразумевает детальных знаний технологий. У меня нет проблем разобраться в новой технологии или стандарте достаточно быстро.
Так бывает, люди возвращаются и в Россию, и в большие компании (в маленькие, наверное, тоже). Я здесь даже не один такой, вернувшийся. И, да, мне здесь нравится. Внутри компании история опубликована со всеми паролями и явками) просто вовне мне важна приватность. Я просто постарался рассказать свою историю как есть, без претензии на то, что всё в ней правильно и единственно возможно. И без лишних подробностей, потому что здесь уже много постов про Австралию. Ну и хотелось сказать, что уехать - вариант, вернуться - тоже вариант.
Про Канаду я ответил выше, что тогда не было спецусловий для айтишников в плане получения виз. Про Ирландию - наверное, это был вариант, но он тогда активно мной не рассматривался, и, вроде, не был таким популярным, как сегодня. За семь лет много чего изменилось, в том числе тогда нельзя было прочитать столько реальных историй российских ИТ-специалистов. В Австралии, с одной стороны, менее дружелюбная система по сравнению с релокацией к конкретному работодателю. Но, на самом деле, в ней много удобства и свободы: если что-то в этой компании не понравилось, у тебя есть свобода для маневра. Про UK: на тот момент (опять же 6 лет назад), исходя из опыта ближнего круга, там инженеру работу с релокацией было найти сложнее, чем во многих других странах.
Спасибо за такой содержательный комментарий, и за то, что опытом поделились. По поводу премьера согласен. Когда принимал решение о переезде, мне хотелось относительно радикально сменить сферу деятельности. Для Австралии же это было слишком радикально) Там я просто не видел таких возможностей, неважно занимаешься ты самообучением или нет. И, конечно, поддерживаю, что в в ит нельзя им не заниматься в принципе, в том или ином формате.
Почти во всех случаях возникающие проблемы – это результат тех или иных ограничений. Например, в одном проекте, где мы упёрлись в потолок производительности, проблемой было ограниченное число выделяемых на сервис виртуальных машин. А у заказчика из поста выше есть ограничения не только на число ВМ (ограничение продиктовано стоимостью обладания каждой отдельной машиной), но и на возможности команд, которые будут отдавать свои данные. Проблема производительности на тестовой инсталляции не возникала, она обозначена исключительно как потенциальная. И для решения её предложен вариант близкий к тому, какой вы описываете: поднимать дополнительные logstash для натравливания на разные очереди.
Устанавливаем компоненты разными путями: всё зависит от ИТ-инфраструктуры и требований заказчика. Где-то всё ставится в Kubernetes/OpenShift, где-то компоненты распределяются частями: что-то в Kuber, что-то на виртуализации, бывает даже на железных серверах. Естественно, все процессы максимально автоматизируются плейбуками.
Спасибо за интерес. Напишите нам, пожалуйста, в личные сообщения или на Email :), познакомимся, и мы вам отправим презентацию и ответим на вопросы.
Что придумали маркетологи и разнесли журналисты, уже никуда не денется. Придется привыкать)
Спасибо)
Мы рекомендуем начать с вашего окружения и где вы собираетесь разворачивать кластеры K8s.
Tanzu CE поддерживает несколько платформ – VMware vSphere, AWS, Azure и пока в экспериментальном режиме локальный docker. Tanzu CE не поможет, если вы хотите развернуть K8s на физических серверах.
Одно из основных преимуществ Tanzu CE – наличие экосистемы продуктов, которые можно доустанавливать с помощью пакетного менеджера и практически «из коробки» получить их интеграцию.
Можно начать с изучения документации: https://tanzucommunityedition.io/docs/latest/. Там же подробно описан процесс инсталляции, работы с пакетами, масштабирование кластеров и многое другое.
Задержки на локальную коммутацию внутри свича несущественны. Они составляют менее 1 микросекунды (не путать с миллисекундой — это в 1000 раз меньше). Для коммутаторов Gen 6 (32 Gb) локальные задержки составляют 780 наносекунд, для коммутаторов Gen 7 (64 Gb) — 460 наносекунд. Весь остальной стек Storage-SAN-Host в протестированных решениях обеспечил ввод/вывод через SAN с задержками порядка 100 микросекунд. А это, на наш взгляд, — отличный результат.
не боян, а первая разработка по теме. То ли еще будет, тут область применения очень широкая.
Добрый день!
Картинка описывает соотношение уровня (порядка) производительности накопителей разного типа. У нас не было цели сравнивать производительность и задержки локального накопителя и накопителей в составе СХД. Речь про Enterprise и общий доступ к дисковым ресурсам с обеспечением отказо- и катастрофоустойчивости.
В СХД, кроме самих дисков, добавляется несколько уровней абстракции: протокол подключения дисков, организация пула хранения и протоколы доступа. На уровне подключения многие производители СХД уже давно используют NVMe. Пулы хранения производители СХД организуют по-разному: кто-то собирает классический RAID, кто-то собирает RAID на чанках, плюс дедупликация, плюс компрессия. На уровне протоколов блочного доступа стандартом де-факто стали FC и iSCSI. Сейчас это семейство пополнилось NVMe over Fabrics включая RoCE и NVMe over FC и возможными их инкапсуляциями. Акцент статьи именно на сравнении протоколов доступа SAN.
По поводу задержек. Производители СХД, чтобы снизить задержки, используют и кэширование, и тиринг. Вместе с современными протоколами доступа это позволяет получать задержки почти на порядок меньше 1 ms при подключении через SAN. Из инструментов для тестирования — vdbench.
Новые тесты и рассказ про методику в планах на будущее.
Спасибо :) Расскажете, что придумали?
Я старался написать про инструменты которые не так известны и популярны как тот же TensorFlow и тем более Apache Airflow/Beam, которые используется не только в ML сфере (хотя в итоге упомянул еще и Jupyter, хоть и с другим посылом :D). В любом случае, инструменты, что вы упомянули определенно заслуживают внимания)
Уточните, пожалуйста, ваш вопрос, обрывается на самом интересном месте.
Спасибо, все 4 поправили)
В комментах выше все по-разному оценивают ситуацию с ИТ в Австралии, и, конечно, везде есть свои плюсы и минусы. Но вот что важно, например, знать про ИТ там, чтобы оценивать: в Австралии интернет adsl 10 мегабит стоит 60 долларов в меcяц. Есть NBN, но он не намного дешевле и не намного лучше.
Да, опыт - ценная штука. Но поехал бы, наверное, в Сидней.
Я сменил направление, но с ИБ уже работал в Остине как инженер, там написано, что я внедрял, например, IDM. Плюс у меня достаточно инженерного опыта в иб было до. Но моя специализация всё-таки была инфраструктурной. Поэтому это смена области. Позиция архитектора не подразумевает детальных знаний технологий. У меня нет проблем разобраться в новой технологии или стандарте достаточно быстро.
Так бывает, люди возвращаются и в Россию, и в большие компании (в маленькие, наверное, тоже). Я здесь даже не один такой, вернувшийся. И, да, мне здесь нравится. Внутри компании история опубликована со всеми паролями и явками) просто вовне мне важна приватность. Я просто постарался рассказать свою историю как есть, без претензии на то, что всё в ней правильно и единственно возможно. И без лишних подробностей, потому что здесь уже много постов про Австралию. Ну и хотелось сказать, что уехать - вариант, вернуться - тоже вариант.
Про Канаду я ответил выше, что тогда не было спецусловий для айтишников в плане получения виз. Про Ирландию - наверное, это был вариант, но он тогда активно мной не рассматривался, и, вроде, не был таким популярным, как сегодня. За семь лет много чего изменилось, в том числе тогда нельзя было прочитать столько реальных историй российских ИТ-специалистов. В Австралии, с одной стороны, менее дружелюбная система по сравнению с релокацией к конкретному работодателю. Но, на самом деле, в ней много удобства и свободы: если что-то в этой компании не понравилось, у тебя есть свобода для маневра. Про UK: на тот момент (опять же 6 лет назад), исходя из опыта ближнего круга, там инженеру работу с релокацией было найти сложнее, чем во многих других странах.
Я, наверное, не совсем точно написал: холоднее, чем в Канаде) В Австралии климат мне очень понравился.
Спасибо за такой содержательный комментарий, и за то, что опытом поделились. По поводу премьера согласен. Когда принимал решение о переезде, мне хотелось относительно радикально сменить сферу деятельности. Для Австралии же это было слишком радикально) Там я просто не видел таких возможностей, неважно занимаешься ты самообучением или нет. И, конечно, поддерживаю, что в в ит нельзя им не заниматься в принципе, в том или ином формате.