Привет, Хабр!

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)

Приступая к работе в ЦОД, можно легко запутаться в различных типах кабелей, которые используются для соединения и подключения сетевых устройств и серверов. Некоторые из них распространены и в повседневной жизни, а потому хорошо узнаваемы – Ethernet-кабели (с коннекторами RJ-45) и кабели питания (например, с распространенными вилками C13). Но другие, такие как оптические кабели с коннекторами стандарта SFP, LC, SC, силовые с вилкой типа IEC-309 и т. д., известны не так широко.

Если вы проводите какие-либо работы непосредственно в стойке, любая ошибка может стоить дорого – нажата не та кнопка, и клиенты уже в дауне, а любимые и глубоко уважаемые специалисты техподдержки шлют вам тикеты счастья. Даже Uptime Institute в своем исследовании 2021 года отмечает, что в 79% случаев причиной падения серверов в ЦОДах является человеческий фактор.  Всё надо делать вовремя – и нажимать кнопки, и менять комплектующие, и переключать кабели… 

Так вот о кабелях. Чтобы начать с ними работать, было бы неплохо хотя бы знать, как они выглядят и какие функции выполняют. 

Этот материал как раз об этом. 

В первую очередь, он будет полезен в роли шпаргалки сотрудникам-стажерам, только начинающим работу с аппаратной частью ИТ-инфраструктуры. 

Search4Faces

В продолжение двух статей про ЛВС, сегодня поговорим о том, как сделать хороший Wi-Fi для предприятия.

1. Разберем общие вопросы (от юридических моментов до выбора технологий);

2. Кратко и емко пройдемся по вопросам моделирования Wi-Fi;

3. Обсудим настройку сети Wi-Fi (мощность, выбор каналов, роуминг, WMM, Beamforming);

4. Разберем основные ошибки при проведении радио замеров;

5. Проведем эксперимент с микроволновкой на кухне.

Меня зовут Леонид Талалаев, я занимаюсь разработкой внутреннего облака Одноклассников one-cloud, про которое уже рассказывали на Хабре. 

Одноклассники – высоконагруженная социальная сеть, и оптимизировать под высокие нагрузки нам нужно не только сервисы, но и инфраструктуру, на которой они работают. Нередко «узким горлышком» становится сама операционная система и, в частности, механизмы распределения ресурсов ядра Linux. 

В облаке на одном физическом сервере могут одновременно работать десятки контейнеров, конкурирующих за ресурсы. Чтобы обеспечить надежную и эффективную работу, необходимо управлять распределением ресурсов между контейнерами.

Для управления сетевым трафиком до недавнего времени мы использовали решение на основе дисциплины Hierarchical Fair Service Queue из Linux Traffic Control. Сегодня пойдет речь про проблему масштабирования в Linux Traffic Control, известную как root qdisc locking. И про то, как нам удалось ее решить, переделав управление сетевым трафиком с использованием eBPF.

Продолжаем серию статей про BPF — универсальную виртуальную машину ядра Linux — и в этом выпуске расскажем о том, какие типы программ BPF существуют, и как они используются в реальном мире капиталистического чистогана. Кроме этого, в конце статьи приведено некоторое количество ссылок, в частности, на две с половиной существующие книжки про BPF.

В ядре Linux версии 5.9 определено больше тридцати разных типов программ BPF, и про некоторые из этих типов я собираюсь написать по несколько статей, так что эта статья, поневоле, обзорная и не содержит такого количества технических деталей, как предыдущие. Но, тем не менее, мы постараемся, наконец-то, ответить на вопрос, зачем все это нужно и почему вокруг BPF так много шума.

Если вы хотите узнать, как именно BPF помогает эффективно решать задачи защиты от DDoS атак, распределения нагрузки на серверы, реализации сетевого стека kubernetes, защиты систем от нападения, эффективной трассировки систем 24x7 прямо в проде и многие другие, то добро пожаловать под кат.

• Безлимитный объем данных — у нас много данных, в среднем около 10ТБ. Не хочется постоянно думать сколько нужно докупить места в этом месяце и почему вдруг кончилась квота.
• Версионность файлов и логирование — git приучил нас, что все изменения можно видеть и откатить. Поэтому и с файлами должны быть точно так же: любое изменение, удаление должно быть обратимо и легко контролироваться.
• Права доступа — никаких больше общих папок доступных всем. Каждый сотрудник должен иметь свою область видимости.
• Upload без регистрации — клиенты не должны больше искать файлообменники, чтобы прислать нам тяжелый файл. Файлы должны сразу загружаться в наше хранилище без промежуточных сервисов.

«Invidious» — это веб-фронтенд (грубо говоря, веб-клиент) для сайта YouTube. Код проекта написан на языке программирования Crystal, использует СУБД PostgreSQL и распространяется под свободной лицензией AGPLv3+.

В предыдущей статье я рассмотрел возможность создания отказоустойчивого NFS-сервера с помощью DRBD и Proxmox. Получилось довольно неплохо, но не будем останавливаться на достигнутом и теперь постараемся "выжать все соки" из нашей хранилки.

В этой статье я расскажу как подобным образом создать отказоустойчивый iSCSI-таргет, который при помощи LVM мы будем нарезать на маленькие кусочки и использовать под виртуальные машины.

Именно такой подход позволят снизить нагрузку и повысить скорость доступа к данным в несколько раз, это бывает особенно выгодно когда не требуется конкурентный доступ к данным, например в случае когда вам нужно организовать хранилище под виртуальные машины.

Наверное каждый, кто хоть раз озадачивался поиском высокопроизводительного software-defiined хранилища рано или поздно слышал про DRBD, а может даже и имел дело с ним.

Правда на пике популярности Ceph и GlusterFS, которые работают в принципе неплохо, а главное сразу и из коробки, все просто немного подзабыли про него. Тем более что предыдущая версия не поддерживала репликацию более чем на два узла, и из-за чего часто встречались проблемы со split-brain, что явно не добавило ему популярности.

Решение и правда не новое, но вполне конкурентоспособное. При относительно небольших затратах на CPU и RAM, DRBD предоставляет реально быструю и безопасную синхронизацию на уровне блочного устройства. За все это время LINBIT — разработчики DRBD не стоят на месте и постоянно дорабатывают его. Начиная с версии DRBD9 перестает быть просто сетевым зеркалом и становится чем-то бОльшим.

Во первых, идея создания одного распределенного блочного устройства для нескольких серверов отошла на задний план, и теперь LINBIT старается предоставить инструменты оркестрации и управления множеством drbd-устройств в кластере, которые создаются поверх LVM и ZFS-разделов.

Например DRBD9 поддерживает до 32 реплик, RDMA, diskless-ноды, а новые инструменты оркестрации позволяют использовать снапшоты, online-миграцию и много чего другого.

Несмотря на то что DRBD9 имеет инструменты интеграции с Proxmox, Kubernetes, OpenStack и OpenNebula, на данный момент они находится в некотором переходном режиме, когда новые инструменты еще не везде поддерживаются, а старые уже очень скоро будут объявлены как deprecated. Речь идет о DRBDmanage и Linstor.

Я воспользуюсь этим моментом что бы не сильно вдаваться в подробности каждого из них, но более подробно рассмотреть настройку и принципы работы с самим DRBD9.

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Привет! Все мы знаем и любим такие продукты для vulnerability assessment процессов как Nessus, Qualys, Max Patrol и всякие прочие OpenVAS. Одной из основных задач, которые они решают, является обеспечение контроля версионных уязвимостей.

Это довольно простой процесс сравнения установленных версий программного обеспечения на попадание в диапазон "не содержит известных уязвимостей". Ну а дальше ребята, ответственные за информационную безопасность, совместно с разработкой и админами решают какие риски можно принять, а что нужно пропатчить прямо сегодня.

Существует масса разнообразных инструментов для решения этой задачи, но у всех них с нашей точки зрения есть одна общая проблема — они требуют отдельного хлопотного развертывания и порождают в вашей инфраструктуре еще один инструмент с root-овой учетной записью. Но ведь для такого простого действия как сбор информации об установленных пакетах root не нужен! Да и обычно в инфраструктуре уже присутствуют развернутые системы с возможностью консолидации данных, совместной работы и удаленного исполнения команд на серверах. Поэтому мы решили сделать инструмент, который позволил бы в пару кликов развернуть в своей среде систему контроля уязвимостей Linux с минимальными изменениями продакшена.

Что развернуто в большинстве продуктовых систем? Конечно же мониторинг. И довольно часто это Zabbix. Так давайте к нему и прикрутимся!

Привет, Хабр! Мы в Хекслете запустили в этом году открытый и бесплатный проект для новичков: code-basics.ru. Это интерактивные курсы с практикой, рассчитанные на тех, кто вообще никогда не программировал. Мы учим основам программирования и рассказываем про базовое устройство компьютеров.

Сейчас доступен полный курс по PHP и первый модуль по JavaScript. На подходе Racket и Python. Весь исходный код платформы и самих уроков — в open source.

Сегодня хочу рассказать немного о сути Code Basics, его внутренностях и технологическом стеке.

Как в блогах, так и в журналах есть множество статей о том, как собрать NAS своими руками.
И с первого взгляда кажется, что при наличии прямых рук, свой NAS по всем пунктам бьёт покупное решение.
"Фигак, фигак и в продакшн", — и вот уже быстро, дёшево и качественно реализованное хранилище радует вас высокой производительностью и надёжностью.