Эксперты прогнозировали массовое внедрение мобильной связи пятого поколения не раньше 2020 года, но работы идут с опережением. Стандарты 5G могут быть утверждены уже в течение ближайшего года, а тестовый запуск сети для обычных пользователей состоится в 2018 году.
Об ожиданиях по поводу сетей пятого поколения – оправданных и не очень – расскажем под катом.
Читать полностью »
Вне зависимости от того, как долго и тщательно программное обеспечение проверяется перед запуском, часть проблем проявляется только в рабочем окружении. Например, race condition от параллельного обслуживания большого количества клиентов или исключения при валидации непредвиденных данных от пользователя. В результате эти проблемы могут привести к 5хх ошибкам.
HTTP 5хх ответы зачастую возвращаются пользователям и могут нанести ущерб репутации компании даже за короткий промежуток времени. В то же время, отладить проблему на рабочем сервере зачастую очень непросто. Даже простое извлечение проблемной сессии из логов может превратиться в поиск иголки в стоге сена. И даже если будут собраны все необходимые логи со всех рабочих серверов — этого может быть недостаточно для понимания причин проблемы.
Для облегчения процесса поиска и отладки могут быть использованы некоторые полезные приёмы в случае, когда NGINX используется для проксирования или балансировки приложения. В этой статье будет рассмотрено особое использование директивы error_page в применении к типичной инфраструктуре приложения с проксированием через NGINX.
Читать полностью »
Apache Mesos — это централизованная отказоустойчивая система управления кластером. Она разработана для распределенных компьютерных сред c целью обеспечения изоляции ресурсов и удобного управления кластерами подчиненных узлов (mesos slaves). Это новый эффективный способ управления серверной инфраструктурой, но и, как любое техническое решение, не "серебряная пуля".
В некотором смысле суть его работы противоположная уже традиционной виртуализации — вместо деления физической машины на кучу виртуальных, Mesos предлагает их объединять в одно целое, в единый виртуальный ресурс.
Mesos распределяет ресурсы CPU и памяти в кластере для задач в похожей манере, как ядро Linux выделяет ресурсы железа между локальными процессами.
Представим себе, что есть необходимость выполнить различные типы задач. Для этого можно выделить отдельные виртуальные машины (отдельный кластер) для каждого типа. Эти виртуальные машины, вероятно, не будут полностью загруженными и некоторое время будут простаивать, то есть не будут работать с максимальной эффективностью. Если же все виртуальные машины для всех задач объединить в единый кластер, мы можем повысить эффективность использования ресурсов и параллельно с тем повысить скорость их выполнения (в случае если задачи краткосрочные или виртуальные машины не загружены полностью все время). Следующий рисунок, надеюсь, прояснит сказанное:
Но это далеко не все. Кластер Mesos (с фреймворком к нему) способен пересоздавать отдельные ресурсы, в случае их падения, масштабировать ресурсы вручную или автоматически при определенных условиях и т.п.
Пройдемся по компонентам Mesos кластера.Читать полностью »
Один банк, российский филиал крупной европейской банковской группы, поставил перед нами задачу сегментировать сеть. Его серверы были расположены в наших дата-центрах. На момент начала работ у заказчика была отдельная инфраструктура для собственно финансовых операций и физически отделённая от неё большая одноранговая сеть пользователей на пару крупных узлов и множество филиалов. Первая работала как часы, а со второй были сложности. Кроме того, как раз начиналась внутренняя реорганизация под требования 152-ФЗ о персональных данных.
Чтобы понять, как лучше организовать новую сеть, мы запросили соответствие IP-адресов и сервисов на них. Точнее, в конечном итоге нам нужна была карта с тем, что и куда гоняет трафик, чтобы было понятно, что разрешать, а что запрещать.
В этом месте ИБ сказали, что такие документы они представить не могут. И предложили собрать карту трафика самим, так как их, во-первых, самих интересует действительная картина происходящего в сети, а во-вторых, описание трафика и приложений в сети у них пока только в планах. Проще говоря, наше появление для них было отличной возможностью актуализовать картину обмена трафиком в сети — похоже, часто случалось, что ИТ что-то подключала и забывала об этом поставить в известность ИБ.
Так мы начали разбирать весь трафик сети.Читать полностью »
Всем привет.
У нас не так много задач, которым необходим полноценный CI. Некоторое время мы использовали в качестве CI-сервиса Jenkins. Там всё довольно очевидно, он прост и гибок в настройке, имеет кучу плагинов, но пару раз мы столкнулись с OOM-убийцами агентов на слабых машинах и решили рассмотреть в качестве CI-сервиса Gitlab CI, потому что мы любим эксперименты и тем более в комментариях к нашей прошлой статье задавали такой вопрос.
Читать полностью »
Безопасность онлайн-проектов, корпоративных ИТ-ресурсов, дата-центров – один из ключевых приоритетов, требующий постоянного внимания и развития. Термин «DDoS» многим знаком на собственном опыте или хотя бы по сообщениям в прессе. К сожалению, это явление получило широкое распространение. При DDoS-атаке происходит распределенное нападение на ИТ-систему организации для того, чтобы довести ее до отказа. В таком случае легальные пользователи системы не могут получить доступ к ее ресурсам, либо этот доступ затруднен.
DDoS-атакам подвергаются интернет-проекты и сайты по всему миру. Так в 2015 году компанией Wallarm было зафиксировано более 100 млн атак на веб-ресурсы своих клиентов. Нередко такие атаки заказывают конкуренты. Другая причина организации атак – вымогательство путем шантажа.
Читать полностью »
Немаловажный пункт, который очень часто упускают из вида разработчики — это эксплуатация проекта. Как выбрать дата-центр? Как прогнозировать угрозы? Что может произойти на уровне фронтенда? Как балансировать фронтенд? Как мониторить? Как настраивать логи? Какие нужны метрики?
И ведь это только фронтенд, а есть ещё бекенд и база данных. Везде разные законы и логика. Подробнее об эксплуатации highload-проектов в докладе Николая Сивко (Head Hunter) с конференции HighLoad++ Junior.
Мы в Атласе любим, когда все находится под контролем. Это касается и всей серверной инфраструктуры, которая, с годами, превратилась в живой организм из многочисленных виртуальных машин, сервисов и служб. Появилась потребность наблюдать за жизненно важными аспектами IT-составляющей нашей деятельности: мониторить боевой сервер, отслеживать изменения системных ресурсов на виртуалках баз данных, следить за ходом бизнес-процессов и тд. Встал вопрос — как же этого добиться и главное какими инструментами? Стали искать какие-то готовые решения. Перепробовали кучу платных/бесплатных сервисов, которые, якобы, предоставляли бы нам "самую ценную" информацию о состоянии нашей системы. Но, в конечном итоге, все сводилось к каким-то непонятных диаграммам, схемам и цифрам, которые, по сути, для нас не имели никакой ценности.
Так мы пришли к пониманию, что надо собирать что-то самостоятельно. За основу решили взять самую гибкую и продвинутую систему, которую можно настроить для мониторинга чего и как угодно — Nagios. Настроили, поставили, работает — круто! Жаль только интерфейс сего чуда застрял где-то в середине 90-х, а нам хотелось, чтобы еще и визуальная составляющая была на уровне.
Недолгий поиск показал, что лидером среди решений по созданию красивых дашбордов является Grafana. Так и решили выводить весь наш мониторинг из Nagios на мониторах в виде красивых графиков в Grafana. Вопрос остался только в том — как их подружить друг с другом?
К нам периодически поступают обращения о некорректной работе удаленных пользователей, подключенных к 3CX через корпоративный NAT маршрутизатор или сетевой экран. В этой статье предлагаем пошаговое руководство по решению проблем с удаленными подключениями.
К сожалению, 3CX не может гарантировать корректную работу “прямых” удаленных подключений, особенно без использования технологии 3CX Tunnel.
Корректная работа не гарантируется по следующим причинам:
На что следует обратить внимание, если вы столкнулись с проблемами при удаленном подключении?
Одной из важнейших задач при разработке приложений с микросервисной архитектурой является задача мониторинга. Слежение за состоянием сервисов и серверов позволяет не только вовремя реагировать на неисправности, но и анализировать их работу. Наличие такой информации трудно переоценить, ведь она предоставляет дополнительные возможности по улучшению производительности и качества работы Вашего ПО.
К счастью, существует множество решений задачи мониторинга, как платных, так и бесплатных. Я же хочу поделиться опытом практического использования open source системы мониторинга Prometheus.
Читать полностью »
