Искал я как-то себе дешевый VPS сервер. Ну для отладки чего-нибудь, моделирования сетей... Да мало ли еще для чего может понадобится личный сервер? И вот в результатах поиска всплыло, что Oracle предоставляет возможность получить бесплатно и "пожизненно" до двух виртуальных машин (Oracle Cloud Infrastructure Compute). А также еще кое-какие вкусняшки. Зарегистрировался, получил - действительно выдают, действительно работает, и действительно бесплатно. Но хочется же подключить полученные машинки в свою сеть! И, желательно, штатными средствами. Вот из экспериментов и получились две статьи, может быть кому-то они сэкономят часа четыре рабочего времени.

Это обновленный до версии 2020-21 мой список 2003, 2005, 2006, 2007, 2009, 2011 и 2014 годов, который в настоящее время включает все остальные мои списки. Я занимаюсь этим более 17 лет. Вау. Думаю, стоит тратить на это больше времени.

Полная настройка терминального сервера, для работы пользователей с 1с и многими другими программами, особенности лицензирования 1с , HASP, настройка RDG, SSL сертификаты

Как и у каждой уважающей себя техподдержки, у инженеров Veeam есть свой список самых популярных поводов позвонить им в любое время дня и ночи. Это и вечно молодое “У вас неправильно работает ретенш”, и никогда не стареющее “У меня место на дисках кончилось, что делать?”, и прорва других. 

Однако среди них есть простой, казалось бы, вопрос. Он объясняется за 5 минут, но вот парадокс: его объяснение вылетает из головы в течение следующих тридцати секунд. Звучит этот чудо-вопрос примерно так: “После бекапа Veeam нарисовал мне непонятный график и написал, что у меня загрузка сорса 63%, прокси 48%, сети 99%, а таргета 0! А потом ещё и обозвал этот сорс ботлнеком, а у меня там ого-го какая железяка! И что вообще означают эти проценты?”

Сегодня объясню в текстовом виде, чтобы было куда возвращаться и перечитывать на досуге.

Bottleneck (бутылочное горлышко, если переводить в лоб) - самая медленная часть вашей бекапной инфраструктуры. Узкое место или слабое звено, если хотите. Тот самый нехороший человек, которого семеро ждать не должны, но получается, что ждут. Если переключиться на более технический язык, то эта та часть инфраструктуры, в которой данные в среднем проводят больше всего времени. То есть обрабатываются дольше всего. Получается, что это чистой воды вопрос производительности (перфоманса, как принято говорить). И знание ответа на этот вопрос позволит нам понять, какую часть в цепочке обработки данных надо ускорить, дабы повысить общую скорость процесса.

И тут откровение номер раз: чтобы говорить о перфомансе на серьёзных щщах, надо напрямую измерять интересующие нас метрики и проводить их аналитику. Это статистика загруженности дисков, процессоров, памяти и так далее. Словом, построить внутри одного продукта ещё один продукт, только мониторинговый. Поэтому Veeam ничего напрямую не измеряет, однако в логах можно найти шесть метрик, сделанных путём опосредованных измерений. 

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

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

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

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

Рассмотрим какие есть альтернативы :

Erasure Coding — Аналог RAID5, RAID6, но с настраиваемым уровнем четности. При этом резервирование выполняется не поблочно а для каждого объекта отдельно. Наиболее простой способ попробовать erasure coding — это развернуть minio.

DRAID — это на данный момент ещё не выпущенная возможность ZFS. В отличие от RAIDZ DRAID имеет распределённый parity block и при восстановлении задействует сразу все диски массива, благодаря чему лучше переживает отказы дисков и быстрее восстанавливается после сбоя.

Уже несколько месяцев прошло с момента релиза Veeam Backup & Replication 10. Даже была обзорная статья про грядущий релиз. А вот пост-релизной статьи посвящённой более детальному и техническому разбору самой ожидаемой функции новой версии — NAS Backup, так и не было.
Поэтому надо срочно исправляться.

LXD — это системный менеджер контейнеров следующего поколения, так гласит источник. Он предлагает пользовательский интерфейс, похожий на виртуальные машины, но использующий вместо этого контейнеры Linux.

Ядро LXD — это привилегированный демон (сервис запущенный с правами root), который предоставляет REST API через локальный unix сокет, а также через сеть, если установлена соответствующая конфигурация. Клиенты, такие как инструмент командной строки поставляемый с LXD посылают запросы через этот REST API. Это означает, что независимо от того, обращаетесь ли вы к локальному хосту или к удаленному, все работает одинаково.

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

Несомненно, вопрос, вынесенный в заголовок статьи, не нов, поднимался не раз и по нему достигнут консенсус «не особо нужна, и даже может быть вредна».
Однако недавнее обсуждение в комментариях заставило меня ещё раз задуматься.

Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL)… Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.

Да, обычно такое не должно происходить: или мы пишем «понемногу» в мелкие файлы/небольшие блоки метаинформации ФС (скорость линейного чтения которых нас не особо волнует), либо же мы пишем «помногу» в большие файлы и всё будет хорошо. Бывает и дозапись мелкими блоками в большие файлы — логи, например, однако они относительно короткоживущие и особой проблемы я тут не вижу.
Но легко представился вполне реальный сценарий, при котором всё-таки внутренняя фрагментация SSD может проявиться: файл базы данных, в который идёт достаточно активная случайная запись. Со временем он (оставаясь нефрагментированным на уровне операционной системы) окажется физически очень даже фрагментированным, что может существенно снизить скорость seq scan, резервного копирования и т.п.

Для проверки я написал скрипт и провёл тесты.

Спойлер: проблема присутствует (существенно влияет на производительность) только на одной из попавшихся под руки моделей (и та позиционируется производителем не как datacenter, а как десктопная/ноутбучная).

Наверное каждый, кто хоть раз озадачивался поиском высокопроизводительного 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.

Примерно 80% из нас, кто заканчивает университет с какой-либо IT-специальностью, в итоге не становится программистом. Многие устраиваются в техническую поддержку, системными администраторами, мастерами по наладке компьютерных устройств, консультантами-продавцами цифровой техники, менеджерами в it-сферу и так далее.

Эта статья как раз для таких 80%, кто только закончил университет с какой-либо IT-специальностью и уже начал мониторить вакансии, например, на должность системного администратора или его помощника, либо выездного инженера в аутсорсинговую фирму, либо в техническую поддержку 1-й/2-й линии.

А также для самостоятельного изучения или для обучения новых сотрудников.

За время своей трудовой деятельности в сфере IT я столкнулся с такой проблемой, что в университетах не дают самую основную базу касательно сетей. С этим я столкнулся сначала сам, когда, после окончания университета, ходил по собеседованиям в 2016 году и не мог ответить на простые (как мне сейчас кажется) вопросы. Тогда мне конечно показалось, что это я прохалтурил и не доучил в университете. Но как оказалось дело в образовательной программе. Так как сейчас, я также сталкиваюсь с данным пробелом знаний, когда обучаю новых сотрудников.

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

Именно поэтому я решил собрать основные темы в одну статью и объяснить их как можно проще «на пальцах».