Русский
Русский
English
Статистика
Реклама

Системное администрирование

Перевод Кунг-фу стиля Linux глобальный поиск и замена строк с помощью ripgrep

17.11.2020 16:15:10 | Автор: admin
Даже те, кто пользуется Linux лишь от случая к случаю, вероятно, знают о том, как работать с grep. При этом не нужно быть экспертом в сфере регулярных выражений для того чтобы без особых сложностей пользоваться grep для поиска в файлах строк, соответствующих простым последовательностям символов или сложным шаблонам. Конечно, grep это отличный инструмент для поиска информации. Но что если нужно что-то найти, а потом заменить это на что-то другое? Например, может быть, нужно изменить все найденные слова HackADay на Hackaday. Тут можно применить sed, но этой утилитой пользоваться довольно сложно. Для решения этой задачи можно было бы воспользоваться awk. Но, учитывая то, что речь идёт о языке программирования, использовать его для решения столь простой и распространённой задачи это, пожалуй, чересчур. Именно идея, заключающаяся в простом решении вышеописанной задачи, и лежит в основе утилиты ripgrep (соответствующая ей команда выглядит как rg). С помощью rg можно решать те же задачи, что решает grep, но при этом пользоваться более современными регулярными выражениями и, кроме того, не только искать строки, но и выполнять их замену.



Об установке ripgrep


Лучше всего, если вам удастся установить ripgrep из репозиториев, доступных в вашем дистрибутиве Linux. Когда я попробовал установить ripgrep в KDE Neon, мне было сообщено, что одну версию ripgrep можно установить с помощью apt, а ещё одну, более свежую, можно установить из Snap-пакета. Я не фанат Snap-пакетов, но я, всё равно, пошёл именно таким путём. Система сообщила, что мне нужно добавить ключ --classic к команде установки пакета, так как ripgrep может воздействовать на файлы, находящиеся за пределами Snap-песочницы. Так как смысл существования ripgrep заключается в том, чтобы менять содержимое файлов, подобное сообщение не показалось мне неожиданным, и я установил ripgrep.

Простой пример использования ripgrep


Если вы хотите использовать rg в том же качестве, что и grep, вы вполне можете так и поступить. Единственное заметное отличие заключается в том, что rg показывает номер строки при выводе данных в stdout.


Команда rg выводит номер строки

Если вам это не нужно запускайте rg с ключом -N. Указать то, на что надо заменить найденную строку, можно с помощью ключа -r.


Использование ключей -N и -r

А что если нужно создавать новые файлы, содержащие изменённые варианты исходных? Для этого можно воспользоваться опцией --passthru. Благодаря ей в вывод программы попадают все строки исходных файлов и изменённые, и неизменённые. Потом вывод программы можно записать в новый файл.

С другой стороны, может понадобиться выводить только те части строк, которые совпали с шаблоном, а не строки целиком. Для этого можно воспользоваться опцией -o. При работе с rg, кроме того, можно пользоваться и многими другими опциями, похожими на те, что поддерживает grep. Например, опция -v позволяет инвертировать поиск в результате в вывод программы попадут только те строки, в которых не найден заданный шаблон.

Перезапись файлов


Одна из классических проблем, связанная с многозадачной природой Linux, проявляется при попытке перезаписи файла. Например, попробуйте провести следующий эксперимент:

cd /tmpcp /etc/fstab test.txtcat test.txt # тут будет выведено много всегоcat test.txt > test.txtcat test.txt # вот так дела - теперь файл пуст

Но это, тем не менее, обычный сценарий использования rg. Конечно, выходные данные программы можно отправить во временный файл, а после этого заменить исходный файл на временный. Но это грубоватое решение задачи. Гораздо изящнее эту задачу можно решить с помощью утилиты sponge. Эта утилита копирует в файл то, что поступает на её вход. Но при этом она ждёт до тех пор, пока на её вход перестанут поступать новые данные. Для того чтобы в результате вышеописанного эксперимента не получился бы пустой файл, в нём вторую строку снизу надо заменить на такую команду:

cat test.txt | sponge test.txt

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

rg --passthru 'Jen' -r 'Jennifer' invite.txt | sponge invite.txt

Тонкая настройка rg


По умолчанию rg использует регулярные выражения из Rust. Они известны своей скоростью, но у них, ради достижения высокой производительности, имеются некоторые ограничения. Опция -P позволяет переключиться на использование регулярных выражений PCRE2. Они имеют больше возможностей, но могут работать медленнее. Ещё один вариант воспользоваться ключом --engine=auto. Это приведёт к тому, что rg, по умолчанию, будет использовать регулярные выражения Rust. А если окажется, что используются какие-то возможности, требующие применения PCRE2, rg перейдёт на движок PCRE2. Если в команде будет присутствовать несколько регулярных выражений для обработки всех их будет применён один и тот же движок. Поэтому если среди них будет хотя бы одно регулярное выражение, для обработки которого нужен PCRE2, система использует PCRE2 для обработки всех регулярных выражений.

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


Использование опции -F

У rg есть и множество других опций. Посмотрите справку по этой утилите, воспользовавшись ключом --help. Например, можно искать тексты по шаблонам, охватывающим несколько строк, можно искать данные в бинарных файлах, использовать в качестве признака окончания строки CRLF, выводить заданное количество строк, расположенных до и после найденной строки, фильтровать файлы с использованием внешней программы.

Итоги


Рассмотренная в этом материале утилита rg это всего лишь один из простых инструментов, без которых вполне можно обойтись. Но её использование упрощает решение множества распространённых задач. Безусловно, для того чтобы раскрыть весь потенциал инструментов, напоминающих grep, просто необходимо разобраться с регулярными выражениями. А чтобы изучать их было веселее можете попробовать специальные кроссворды.

Чем вы пользуетесь для поиска текстовых данных в Linux?



Подробнее..

Перевод Кунг-фу стиля Linux упрощение работы с awk

19.11.2020 16:18:00 | Автор: admin
Утилита awk это нечто вроде швейцарского ножа для обработки текстовых файлов. Но некоторые ограничения awk порой доставляют неудобства тем, кто этой утилитой пользуется. Я, для того чтобы упростить работу с awk, создал несколько функций. Но сразу хочу сказать о том, что для работы этих функций нужны возможности GNU-версии awk. Поэтому для того чтобы воспроизвести то, о чём я буду рассказывать, вам совершенно необходимо использовать gawk и ничего другого. Возможно, в вашей системе настроено сопоставление /usr/bin/awk с чем-то, и это что-то может представлять собой gawk. Но это может быть и mawk, и какая-то другая разновидность awk. Если вы используете дистрибутив Linux, основанный на Debian, то знайте, что команда update-alternatives это ваш хороший друг. В данном материале я буду исходить из предположения о том, что его читатель использует gawk.



После того, как вы прочитаете эту статью, вы узнаете о том, как пользоваться моей библиотекой дополнительных функций для awk. А именно, речь идёт о разделении строки на поля даже в условиях, когда не существует единого символа, используемого для разделения полей. Кроме того, вы сможете обращаться к полям, используя выбранные вами имена. Например, вам не придётся помнить о том, что $2 это поле, содержащее сведения о времени. Вместо этого можно будет просто воспользоваться конструкцией наподобие Fields_fields[time].

Проблема awk


Утилита awk берёт на себя решение множества стандартных задач обработки текстовых файлов. Она читает файлы, считывая по одной записи за раз. Обычно запись это одна строка. Затем awk разбивает строку на поля, ориентируясь на пробелы или на другие символы, используемые в качестве разделителей полей. Можно написать код, который что-то делает со считанной строкой или с отдельными полями. Эти стандартные возможности awk хорошо подходят для решения многих задач, особенно учитывая то, что можно настраивать разделители полей и признак конца записи. Такому формату соответствует удивительно большое количество файлов.

Правда, так устроены далеко не все файлы. Если нужно работать с данными из каких-нибудь логов или из баз данных, такие данные могут быть отформатированы с использованием самых разных подходов. Например, в некоторых полях могут присутствовать структурированные данные, при оформлении которых используются различные разделители. Это, конечно, не значит, что такие данные нельзя обработать с помощью awk. Так как в нашем распоряжении оказывается вся строка, с этой строкой можно сделать всё, что нужно. Но при обработке подобных строк усложняется логика программы. А главная цель использования awk это упрощение работы.

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

^([0-9]{8})([a-zA-Z0-9]{6})([-+.0-9]+),([-+.0-9]+)$

Подобные записи будет непросто разделить на поля с использованием стандартных возможностей awk. Поэтому для разбора подобных записей приходится писать код самостоятельно.

Если в записях файла имеются единообразно оформленные поля, но при этом неизвестно их точное количество, тогда, возможно, имеет смысл воспользоваться FS или FPAT. Вот материал, в котором идёт речь об использовании FPAT при обработке HEX-файлов с помощью awk. В рассматриваемой библиотеке применяется немного другой подход. Её можно использовать для полного разбора строки на составные части. Например, часть строки может представлять собой поле фиксированной длины, после чего могут идти поля, для оформления которых используется множество различных разделителей. С помощью других методов обрабатывать подобные данные может быть довольно-таки непросто.

Регулярные выражения


Расскажу о функции gawk match. Эта функция, конечно, имеется и в обычном awk, но её возможности в gawk расширены, что упрощает её использование. Обычно эта функция выполняет поиск в строках с использованием регулярного выражения. Она сообщает о том, где начинается фрагмент строки, соответствующий регулярному выражению (если совпадение найдено), и о том, сколько именно символов строки соответствуют регулярному выражению.

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

Например, пусть регулярное выражение выглядит так:

"^([0-9]+)([a-z]+)$"

Обрабатываемая строка выглядит так:

123abc

Массив будет содержать следующие данные:

array[0] - 123abcarray[1] - 123array[2] - abcarray[0start] - 1array[0length] - 6array[1start] - 1array[1length] - 3array[2start] - 4array[2length] - 3

Можно даже использовать вложенные выражения. Так, например, регулярное выражение вида ^(([xyz])[0-9]+)([a-z]+)$ при анализе строки z1x даст array[1]=z1, array[2]=z и array[3]=x.

Теория и практика


В теории это всё, что нужно. Можно писать регулярные выражения для разбора строк, а потом обращаться к отдельным элементам строки, пользуясь массивом. На практике же гораздо удобнее будет, если все подготовительные процедуры будут проведены заранее, что позволит работать с данными, используя обычные имена.

Вот пример строки, которую может понадобиться обработать:

11/10/2020 07:00 The Best of Bradbury, 14.95 *****

Здесь имеется дата в формате, принятом в США, время в 24-часовом формате, название товара, цена и рейтинг товара, который может выглядеть как последовательность из 1-5 звёздочек и, кроме того, может отсутствовать. Написание регулярного выражения, способного выделить из этой строки каждое интересующее нас поле, будет достаточно сложной, но решаемой задачей. Вот один из вариантов такого регулярного выражения:

"^(([01][0-9])/([0-3][0-9])/(2[01][0-9][0-9]))[[:space:]]*(([0-2][0-9]):([0-5][0-9]))[[:space:]]+([^,]+),[[:space:]]*([0-9.]+)[[:space:]]*([*]{1,5})?[[:space:]]*$"

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

Библиотека, облегчающая работу с gawk


После того, как вы скачали файлы с GitHub, вы можете поместить функции с именами вида fields_* в свой код. В блоке BEGIN нужно выполнить некоторые настройки. Затем строки обрабатывают с помощью функции fields_process. Вот небольшой пример использования моей библиотеки (код самих функций из библиотеки опущен):

BEGIN {fields_setup("^(([01][0-9])/([0-3][0-9])/(2[01][0-9][0-9]))[[:space:]]*(([0-2][0-9]):([0-5][0-9]))[[:space:]]+([^,]+),   [[:space:]]*([0-9.]+)[[:space:]]*([*]{1,5})?[[:space:]]*$")fields_setupN(1,"date")fields_setupN(2,"month")fields_setupN(3,"day")fields_setupN(4,"year")fields_setupN(5,"time")fields_setupN(6,"hours")fields_setupN(7,"minutes")fields_setupN(8,"item")fields_setupN(9,"price")fields_setupN(10,"star")}{v=fields_process()... тут будет ваш код...}

В своём коде для обработки вышеприведённой строки вы можете воспользоваться, например, такой конструкцией:

cost=Fields_fields["price"] * 3

Как по мне, так это сильно упрощает работу. Функция fields_process возвращает false в том случае, если ей ничего не удалось найти. При этом, если нужно, можно работать с обычными awk-полями вроде $0 или $2.

Об устройстве предлагаемых функций


Мои функции основаны на двух механизмах. Во-первых это gawk-расширение функции match. Во-вторых это механизм ассоциативных массивов awk. Ранее я добавил именованные ключи к существующему массиву найденных совпадений. Поэтому к данным можно обращаться любым способом. Но я модифицировал массив, поэтому он является локальным, так как мне почти никогда не нужна эта возможность, и, таким образом, если понадобятся все данные из массива, нужно будет отфильтровать из него все дополнительные поля.

Часто имеет смысл начинать регулярное выражение с символа ^ и заканчивать символом $ для того чтобы ориентироваться на обработку всей строки. Главное не забывать о том, что регулярное выражение должно, как в примере, учитывать использование пробелов. Это часто бывает нужно в том случае, когда имеются поля, которые могут содержать пробелы. Но если надо, чтобы пробелы, в любом случае, играли роль символов-разделителей полей, то вам, возможно, лучше использовать стандартную схему разбора строк.

Ещё один интересный приём заключается в получении остатка строки всего того, что осталось после обработки первых полей. Сделать это можно, добавив в конец регулярного выражения конструкцию (.*)$. Главное не забудьте задать тег для этой конструкции, используя fields_setupN, что позже позволит обратиться к этим данным.

К моей библиотеке можно добавить простое расширение, которое превращает шаблон в массив шаблонов. Функция обработки строк может перебирать и испытывать элементы массива до тех пор, пока не найдёт совпадение с одним из них. Затем функция возвращает индекс сработавшего шаблона или false в том случае, если не найдено совпадения ни с одним шаблоном. Вероятно, при таком подходе нужно будет предусмотреть использование различных наборов тегов полей для каждого из шаблонов.

Пользуетесь ли вы gawk? Планируете ли применять функции, предложенные автором этого материала?



Подробнее..

Linux в режиме реального времени

23.11.2020 14:22:47 | Автор: admin


Операционная система реального времени необходима, когда к работе процессора или потоку данных предъявляются жесткие временные требования. Таким образом она часто выполняет роль блока управления в специальных устройствах. Проведение научных экспериментов, приложения визуализации в медицине, промышленные устройства управления являются системами реального времени. Механизмы впрыска топлива автомобильных двигателей, контроллеры бытовой и военной техники также являются системами реального времени.

При этом разные события имеют различные временные требования. Например, требование к задержке для антиблокировочной тормозной системы может составлять от 3-5 миллисекунд. То есть с момента, когда колесо впервые обнаруживает, что оно скользит, у системы, управляющей антиблокировочными тормозами, есть от 3-5 миллисекунд, чтобы отреагировать и исправить ситуацию.

Возможности ядра в реальном времени существует уже более десяти лет в экосистеме программ с открытым исходным кодом. Столько же времени доступна поддержка Red Hat Enterprise Linux (RHEL) для ядра реального времени. Тем не менее многие системные администраторы неверно истолковывают его основные концепции и фактическое рабочее поведение. В этой статье я опишу некоторые из его основных функций, отличия от стандартного ядра и шаги по установке.

Планировщик ЦП в реальном времени


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

Мы называем задержкой события время, которое проходит с момента возникновения события до момента его обслуживания. Есть два типа задержек, оказывающих влияние на производительность ОС реального времени.

  • Задержка прерывания относится к периоду времени от поступления прерывания в CPU до запуска процедуры обработки. Когда происходит событие, ОС должна сначала завершить выполняемую инструкцию и определить тип возникшего прерывания. Затем он должен сохранить состояние текущего процесса до обработки прерывания с помощью специальной процедуры, interrupt service routine (ISR).


    Рис. 1 Задержка прерывания.
  • Время, необходимое диспетчеру планирования для остановки одного процесса и запуска другого, называется задержкой диспетчеризации. Предоставление задач реального времени с немедленным доступом к процессору требует, чтобы ОС реального времени минимизировали также и эту задержку. Наиболее эффективным методом поддержания низкой задержки отправки является предоставление ядер с приоритетным прерыванием.


    Рис. 2 Задержка диспетчеризации.


Планировщик с учетом приоритетности процессов


Наиболее важной особенностью ОС реального времени немедленно реагировать на критический процесс, требующий доступ к ресурсам CPU. В результате планировщик для операционной системы реального времени должен поддерживать алгоритм приоритетного прерывания. Такие алгоритмы назначают каждому процессу приоритет в зависимости от его степени важности. Если планировщик также поддерживает приоритетное прерывание, текущий процесс на CPU по запросу будет вытеснен в пользу более приоритетного процесса.


Рис. 3 Классификация планировщиков.

Существует несколько алгоритмов для планировщика в реальном времени.

  • Rate-Monotonic Scheduling алгоритм со статическим приоритетом класса планирования. Статические приоритеты назначаются в соответствии с продолжительностью цикла задачи, вследствие чего более короткие циклы имеют более высокий приоритет исполнения. В худшем случае КПД загрузки центрального процессора ограничен следующей величиной.


    При числе процессов n, стремящемся к бесконечности ряд будет сходиться к ln2 0.693147.
  • Earliest-deadline-first (EDF) Scheduling динамически назначает приоритеты в соответствии с крайним сроком. Чем раньше крайний срок, тем выше приоритет и чем позже крайний срок, тем ниже приоритет. В отличие от RMS, планировщик EDF не требует, чтобы процессы были периодическими и постоянно запрашивали одно и то же количество процессорного времени на пакет. Единственное требование состоит в том, чтобы процесс объявлял свой крайний срок планировщику, когда он готов к запуску.


    Рис. 4 Планировщик EDF.

    На рисунке видим общий принцип работы планировщика. На точке 4 был замещён T1 и его место занял T2 так как его крайний срок наступал раньше, чем у T2. После отработки T3 планировщик вернулся к T1, который завершился на отметке 21.
  • POSIX real-time-scheduling. Стандарт POSIX.4 определяет три политики планирования. Каждый процесс имеет атрибут планирования, который может быть выставлен в одну из трех вариантов политики.

    • SCHED_FIFO политика упреждающего планирования с постоянным приоритетом, при которой процессы с одинаковым приоритетом обрабатываются в порядке первым пришел первым обслужен (FIFO). Данная политика иметь не менее 32 уровней приоритета.
    • SCHED_RR политика аналогична SCHED_FIFO, но использует метод временного среза (циклический перебор) для планирования процессов с одинаковыми приоритетами. Он также имеет 32 уровня приоритета.
    • SCHED_OTHER политика не определена и зависит от системы; может вести себя по-разному в разных реализация.


Установка и использование RHEL Real Time


Для начала следует подключить репозиторий Red Hat Enterprise Linux для Real Time, и установить группу пакетов RT.

[root@server ~]# subscription-manager repos --enable rhel-8-for-x86_64-rt-rpms[root@server ~]# yum groupinstall RT

В составе RT идут эти компоненты:

  • kernel-rt ядро с функционалом реального времени;
  • rt-setup установка окружения Red Hat Enterprise Linux Real Time;
  • rt-tests утилиты тестирования функций RT;
  • rt-eval для оценки возможности применять RT на данной системе;

После установки RT и перезагрузки нужно убедиться, что загружено ядро kernel-rt.

[root@server ~]# uname -aLinux rt-server.example.com 4.18.0-80.rt9.138.el8.x86_64 

Посмотрим на некоторые отличия kernel-rt от стандартного ядра.

  • При высокой нагрузке происходит проверка приоритета задачи (1-99).
  • Высокоприоритетным (99) задачам отдается предпочтение при доступе к ресурсам центрального процессора.
  • Не задействует политику Completely Fair Scheduling (CFS).
  • Использует политику SCHED_FIFO, либо же SCHED_RR.


Рис. 5 Сравнение kernet_rt со стандартным ядром.


На графике показан замер времени отклика из миллиона повторений для систем, использующих ядра RHEL Linux 7 и RHEL Real Time соответственно. Синие точки на этом графике представляют время отклика (в микросекундах) систем со стандартным ядром RHEL 7, а зеленые RHEL 7 Real Time. Из графика видно, что особенность kernel-rt в гораздо меньшей дисперсии и, соответственно, в большей предсказуемости времени отклика системы.

Настройка и тестирование


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

Утилита hwlatdetect из пакета rt-tests покажет задержки, вызванные аппаратным и микропрограммным обеспечением, путем опроса источника тактовых импульсов и поиска непонятных пропусков.

[root@server ~]#  hwlatdetect --duration=60shwlatdetect:  test duration 60 secondsdetector: tracerparameters:Latency threshold: 10usSample window:     1000000usSample width:      500000usNon-sampling period:  500000usOutput File:       NoneStarting testtest finishedMax Latency: Below thresholdSamples recorded: 0Samples exceeding threshold: 0

В данном примере parameters указывает на задержку и способ обнаружения. Порог задержки по умолчанию был выставлен на 10 микросекунд (10 s).

RT имеет также утилиту rteval для тестирования производительности системы в реальном времени под нагрузкой. Программа создаёт большую нагрузку на систему, используя планировщик SCHED_OTHER, а затем измеряет отклик в реальном времени на каждом из активных CPU. Цель в том, чтобы постоянно выполнялись различные задачи, такие как выделение / освобождение памяти, дисковый I/O, вычисления, копирование памяти и другие.

Каждый поток измерений берет временную метку, бездействует в течение некоторого интервала, а затем принимает другую временную метку после пробуждения. Задержка по результатам измерения равна t1 - (t0 + i), где

  • t1 фактическое время измерения;
  • t0 теоретическое время пробуждения первой временной метки;
  • i интервал ожидания.

Отчет утилиты rteval выглядит так.

System:Statistics:Samples:           1440463955Mean:              4.40624790712usMedian:            0.0usMode:              4usRange:             54usMin:               2usMax:               56usMean Absolute Dev: 1.0776661507usStd.dev:           1.81821060672usCPU core 0       Priority: 95Statistics:Samples:           36011847Mean:              5.46434910711usMedian:            4usMode:              4usRange:             38usMin:               2usMax:               40usMean Absolute Dev: 2.13785341159usStd.dev:           3.50155558554us

Использованные материалы





Подробнее..

Перевод Кунг-фу стиля Linux наблюдение за файлами

24.11.2020 12:18:29 | Автор: admin
Linux или Unix приятно отличаются от многих других операционных систем тем, что Linux-программы часто выдают сообщения, которые записываются в какой-нибудь журнал. А многие команды даже можно настроить так, чтобы они генерировали бы больше сообщений, чем обычно. Я знаю о том, что в Windows есть средство для просмотра событий, но множество программ не особенно охотно делятся сведениями о своей работе. Это усложняет поиск источников проблем в тех случаях, когда что-то идёт не так, как ожидалось.



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

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

Давайте рассмотрим пример анализа файла, который можно назвать матерью всех логов. Это /var/log/syslog. Попробуйте вывести его на экран с помощью команды cat или less (я, в своих системах, всегда создаю псевдоним more для команды less, поэтому если я вдруг упомяну команду more знайте, что я имею в виду less). Этот файл, вероятнее всего, будет очень большим, его размеры будут постоянно расти. В обычной настольной системе он ведёт себя довольно спокойно, но в некоторых старых системах и на серверах в нём можно увидеть последствия бурной деятельности разных программ. В любом случае, за исключением тех ситуаций, когда система только что загружена, в нём будут многие страницы данных.


Хакерский подход к анализу логов

Поиск информации, которая уже присутствует в этом файле, особых сложностей не вызывает. Тут можно воспользоваться grep, или можно загрузить копию файла в текстовый редактор. Проблема заключается в анализе свежей информации. Попробуйте подключить USB-устройство к системе (или отключите его от неё). Вы увидите, как в syslog появились новые записи. А что если в него постоянно добавляются десятки сообщений? Как за ними уследить?

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

Команда tail


Традиционный подход к наблюдению за файлами, постоянно пополняемыми информацией, заключается в использовании команды tail. Она берёт большой файл и возвращает лишь некоторое количество его последних строк. Эту команду можно вызвать с опцией -f. Тогда она будет ждать появления в файле новых данных и выводить их. Эта опция весьма полезна для наблюдения за файлами, в которые постоянно добавляется что-то новое. Опция -F приводит к практически такому же эффекту, но благодаря ей tail, если не может сразу открыть файл, будет продолжать пытаться открыть его. С помощью опции -m можно задавать количество выводимых последних строк файла, а с помощью опции -c количество байтов. Опция -s позволяет задавать частоту проверки изменений файла.

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

tail -f /var/log/syslog

Вы увидите несколько строк из конца файла системного журнала. А если подключить к компьютеру USB-устройство или отключить такое устройство от компьютера, можно увидеть, как сведения, попавшие в журнал, практически мгновенно выводятся на экране. Повторно запускать tail при этом не нужно.

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

Меньше значит больше: полезные возможности команды less


У команды less есть опция +F, которая превращает эту команду в хорошую замену команды tail. На самом деле, если вы испытаете команду, приведённую ниже, вас может посетить мысль о том, что результаты её работы не очень-то и отличаются от результатов работы tail. Вот эта команда:

less +F /var/log/syslog

Вот как вывод этой команды выглядит на моём компьютере.


Результаты работы команды less

Обратите внимание на то, что в нижней части экрана имеется надпись Waiting for data. В данный момент утилита less работает практически так же, как и tail. Но если нажать CTRL+C произойдёт кое-что интересное. Ну что-то, возможно, и произойдёт. Попробуйте. Если less переходит в командный режим значит всё в порядке. Теперь можно заниматься всем тем, чем обычно занимаются, просматривая файлы с помощью less. Если же по нажатию CTRL+C работа less прекратится, это будет означать, что ваш Linux-дистрибутив помог вам, установив некоторые стандартные опции less с использованием переменной окружения LESS. Попробуйте такую команду:

set | grep LESS

Если вы увидите, что в списке опций имеется --quit-on-intr, это будет значить, что проблема заключается именно в данной строке. Её надо убрать. После этого переключиться в командный режим можно с использованием CTRL+C. Это, кроме того, означает, что вам нужно запомнить, что для выхода из less используется команда q. Если вы вышли из режима наблюдения за файлом и хотите снова в него вернуться просто нажмите F.

Если вы пользуетесь less в обычном режиме (то есть не использовали при запуске утилиты опцию +F), вы можете нажать клавишу F на клавиатуре для перехода в tail-режим. А ещё интереснее то, что, нажав ESC-F можно в этом режиме что-то искать, при этом, если в поступающих данных найдётся совпадение с тем, что вас интересует, система вам об этом сообщит.

Команду less можно ещё использовать с ключом --follow-name. Это позволит добиться того же эффекта, что и использование опции -F команды tail.

Наблюдение за файлами с помощью команды watch


Иногда файл, за которым нужно наблюдать, не пополняется новыми данными, добавляемыми в его конец, а просто иногда меняется. Например, это файл /proc/loadavg или многие другие файлы из директории /proc. Использование команд tail или less не особенно хорошо подходит для наблюдения за такими файлами. Тут нам на помощь придёт команда watch:

watch -n 5 cat /proc/loadavg


Результат выполнения команды watch

Эта команда вызывает cat каждые 5 секунд и аккуратно выводит результат. Команда watch поддерживает множество полезных опций. Например, опция -d позволяет выделять отличия, а -p позволяет задействовать высокоточный таймер. Опция -c включает поддержку цвета.

Использование текстового редактора для наблюдения за файлами


Возможно, используемый вами текстовой редактор поддерживает tail-режим. При работе с emacs, например, есть несколько способов это организовать. Не буду рассказывать о том, как это сделать. Просто порекомендую вам эту отличную статью. Я не отношу себя к экспертам в области vim, но полагаю, что если вы пользуетесь этим редактором и хотите наблюдать за файлами, вам понадобится специальный плагин.

Если вы не ищете лёгких путей, то вам, возможно, подойдёт инструмент наподобие lnav, который сделан специально для просмотра логов. Просмотрщики журналов имеются, кроме того, в KDE и Gnome.

Итоги


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

Те команды, о которых мы говорили, могут пригодиться и тем, кто пользуется настольным дистрибутивом Linux, и тем, кто работает с серверами или с Raspberry Pi.

Как вы наблюдаете за постоянно изменяющимися файлами в Linux?



Подробнее..

Перевод Загрузка операционной системы с виниловой пластинки

25.11.2020 12:06:49 | Автор: admin
Большинство компьютеров загружаются с встроенного накопителя. Это может быть обычный жёсткий диск или SSD. Иногда они загружают ОС из сети, или, в крайнем случае, если загружаться больше неоткуда, с USB-флешки или с DVD. Как по мне так всё это скука смертная. Как насчёт загрузки ОС с виниловой пластинки?


10-дюймовая пластинка, время проигрывания которой составляет 6 минут 10 секунд при скорости 45 оборотов в минуту это загрузочный диск DOS размером 64512 байт

Для проведения этого необычного эксперимента персональный компьютер (а точнее IBM PC) подключён к проигрывателю виниловых пластинок через усилитель. Тут имеется маленький ROM-загрузчик, управляющий встроенным кассетным интерфейсом PC (который, пожалуй, никогда и никем не используется). Этот загрузчик вызывается BIOS в том случае, если все остальные способы загрузки не сработали (то есть загрузка с дискеты и с жёсткого диска). Проигрыватель воспроизводит аналоговую запись содержимого небольшого RAM-диска, предназначенную только для чтения, размер которой составляет 64 Кб. В этой записи имеется ядро FreeDOS, модифицированное мной так, чтобы его размер уложился бы в существующие ограничения. Здесь же есть компактный вариант COMMAND.COM и пропатченная версия INTERLNK, которая позволяет передавать файлы по принтерному кабелю и переделана так, чтобы она работала бы в FreeDOS. Загрузчик читает образ диска с пластинки через кассетный модем, записывает образ в память и загружает с его использованием ОС. Полагаю, не так уж всё это и сложно.


Виниловый загрузчик в ROM (он ещё может быть записан на жёсткий диск или на дискету, но это уже будет нечестно)

Если немного углубиться в технические детали, то окажется, что перед нами некий симбиоз BootLPT/86 и 5150CAXX без поддержки порта принтера. Он тоже хранится в ROM, в слоте расширения BIOS, но это необязательно. Для подключения усилителя к компьютеру используется кабель, аналогичный тому, что применяется в 5150CAXX, но тут не используется передача данных от компьютера к подключённому к нему устройству.

Кассетный интерфейс это всего лишь выход, представленный каналом 2 таймера динамика PC и вход, который представлен 4 каналом порта C 8255A-5 PPI (PC4, I/O-порт 62h, бит 4). Для программной (де)модуляции используются возможности BIOS INT 15h.

Загрузочный образ это тот же 64-килобайтный образ RAM-диска BOOTDISK.IMG, ссылку на загрузку которого можно найти здесь. Данные образа, с использованием 5150CAXX, преобразуются в вид, совместимый с протоколом IBM cassette tape, а получаемый аудиосигнал уходит прямо в систему записи виниловых пластинок.

Запись осуществляется с использованием кривой выравнивания RIAA, которую предварительный усилитель обычно обращает в процессе воспроизведения звука. Но делает он это не идеально. А значит на усилителе нужно выполнить коррекцию сигнала. Именно поэтому я и воспользовался усилителем, так как мне не удалось получить нужный сигнал, подав звук на компьютер сразу от предусилителя. В моём случае, используя винтажный усилитель Harman&Kardon 6300 и интегрированный предусилитель MM Phono, мне пришлось убавить высокие частоты (-10дБ/10кГц), поднять басы (+6дБ/50Гц) и уменьшить уровень громкости до получения пиков примерно в 0,7 вольта, что позволило предотвратить искажения звука. Всё это делалось, конечно, при отключённой коррекции фазы и громкости.

Безусловно, кассетному модему совершенно наплевать на то, откуда именно приходит сигнал. При этом, конечно, важно, чтобы запись была бы чистой, не содержала бы щелчков и треска (винил) или недостатков, связанных с модуляцией или частотой сигнала (магнитная лента). Всё это может прервать поток данных. Правда, звук вполне может немного плавать, скорость воспроизведения может варьироваться в пределах 2-3%. Это не мешает правильной передаче данных.


EPROM-модуль с загрузчиком

Итоги



Загрузка компьютера с проигрывателя виниловых пластинок

Вот и всё! Если кому-то нужен загрузчик, сделанный для чипа 2364 (через адаптер можно использовать и чипы 2764), то его код можно найти здесь. Он рассчитан на работу с IBM 5150 с монохромным дисплеем и с как минимум 512 Кб RAM, что (вот уж совпадение) напоминает компьютер, с которым экспериментирую я. Ссылку на образ загрузочного диска можно найти в этом материале. А вот тот же образ, но уже в звуковом виде.

Приходилось ли вам загружать компьютеры с использованием каких-нибудь необычных способов?



Подробнее..

Личная файлопомойка. Как я настраивал файлообменник на VPS

26.11.2020 12:17:06 | Автор: admin


Эпоха флешек давно канула в Лету. Что, впрочем, неудивительно: незаменимый инструмент для переноса файлов в кармане утратил свою актуальность с появлением облачных сервисов доступных везде, где есть интернет, причем практически с любого устройства. Однако в этой бочке меда не обошлось без маленькой ложки дегтя. Во-первых, бесплатные тарифы у большинства вендоров накладывают строгие ограничения на объем облачного хранилища и количество устройств, на которые можно установить приложение для синхронизации. Во-вторых, используя публичные облачные сервисы, вы доверяете свои файлы сторонней компании и никак не можете повлиять на их безопасность. В-третьих, подобные хранилища не слишком удобны для командной работы, которая весьма актуальна в период мировой короновирусной истерии пандемии. Выход? Можно смириться, а можно организовать сетевое файловое хранилище самостоятельно! Один из примеров решения этой задачи мы сейчас и рассмотрим.

Зачем, Холмс?


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

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

Безусловно, за $9.99 в месяц можно купить 2 терабайта в облаке у Dropbox, но там нет возможности многопользовательской работы. При нынешнем курсе доллара аренда виртуального сервера с дисковым объемом 40 Гб, но без ограничений на количество подключений, выйдет примерно в ту же сумму, а если выбрать конфигурацию попроще с одним ядром то даже дешевле. Определенная часть этого дискового пространства будет занята операционной системой, но для хранения файлов останется минимум 20 Гбайт, чего для моих целей вполне достаточно.

При этом файловое хранилище на VPS имеет целый ряд других неоспоримых преимуществ:
можно публиковать веб-сайты прямо из общей папки;
можно организовать доступ к нему с использованием SFTP;
можно настроить торрент-клиент для загрузки и выгрузки контента;
в том же контейнере можно смонтировать сервер NFS или SMB для использования VPN.

В общем, немного поразмыслив, я решил настроить File Storage на виртуальном сервере от этот провайдер использует в своей инфраструктуре преимущественно Windows Server, что намекает на относительную простоту организации удаленного хранилища (ха-ха!). Тем более, на моих устройствах (за исключением, разумеется, мобильных) установлена винда и macOS, поэтому серьезных проблем с подключением к удаленному серверу возникнуть уж точно не должно, подумал я (ха-ха два раза).

Матчасть


Virtual Private Server (VPS) чаще всего покупают для хостинга сайтов, но в отличие от обычного хостинга, он позволяет изолированно запускать несколько приложений в одном и том же контейнере. В целом, VPS вполне можно использовать для организации личного файлового хранилища, поскольку:
средства виртуализации VPS обеспечивают достаточный уровень безопасности, в связи с чем такое хранилище можно считать относительно надежным;
как правило, провайдер самостоятельно организует резервное копирование собственных контейнеров, либо предоставляет средства автоматизации этого процесса, поэтому о бекапах можно особенно не беспокоиться;
виртуальный сервер более дешев по сравнению с выделенным сервером при схожем уровне безопасности и в целом подходит для выбранной цели.

Для реализации своей задумки я выбрал виртуальный сервер в следующей конфигурации:
Windows Server 2019
2 ядра (Intel Xeon);
2 Гб RAM;
40Гб HDD.



Этого вполне достаточно, чтобы использовать наш VPS в качестве удаленного файлового хранилища. После создания сервер сразу же станет доступен нам по RDP к нему можно подключиться либо с помощью клиента удаленного Рабочего стола, либо непосредственно в браузере из Панели управления RuVDS. Необходимые для подключения данные будут дополнительно отправлены по электронной почте, так что не потеряются. Что ж, приступим к самому интересному настройке сервера.

Настройка сервера


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



В окне Мастера добавления ролей и компонентов нажимаем Далее, затем, выбрав вариант Установка ролей и компонентов, снова жмем Далее. Выбираем в списке наш сервер (собственно, он и будет там представлен в единственном экземпляре), и очередным нажатием на кнопку Далее переходим к настройке ролей.



Нас интересует раздел Файловые службы и службы хранилища. Эта роль установлена на сервере по умолчанию. Установите флажок Файловые службы и службы SCSI и разверните расположенный под ним список. Здесь следует дополнительно установить следующие флажки:
Файловый сервер;
Рабочие папки;
Диспетчер ресурсов файлового сервера (в открывшемся окне нажмите Добавить компоненты).

Теперь дважды нажмем Далее и завершим настройку ролей сервера щелчком мыши на кнопке Установить.

Создание нового раздела


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



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



Я решил эту проблему, создав отдельный логический том, отличный от того, на котором установлена Windows там мы сможем развлекаться, как нашей душе угодно. Для этого:
В окне Диспетчера серверов откройте расположенное в верхней части меню Средстива, а в нем Управление компьютером.
В открывшемся окне выберите в левой панели оснастку Управление дисками. Вы увидите единственный диск, на котором расположена операционная система.
Щелкните на диске правой клавишей мыши и выберите Сжать том. При общем объеме диска в 40 Гбайт в поле Размер сжимаемого пространства, Мб я прописал значение 25 000, посчитав, что для работы винде хватит 15 Гбайт дискового пространства.
Щелкните мышью на кнопке Сжать, и дожидитесь, пока Windows освободит место на диске.



После того как в Диспетчере дисков появится неразмеченное свободное пространство, необходимо проделать следующие шаги:
Щелкните правой клавишей мыши в нераспределенной области, и в контекстном меню выберите пункт Создать простой том;
В окне Мастера создания простого тома нажмите Далее, убедитесь, что размер тома соответствует объему неразмеченной области, снова нажмите Далее.
Введите букву диска (по умолчанию D:) и опять нажмите Далее.
Выберите в качестве файловой системы NTFS, размер кластера по умолчанию, установите флажок Быстрое форматирование. Остальные параметры можно оставить без изменений. Нажмите Далее. Затем щелкните мышью на кнопке Готово.



Если теперь мы откроем Проводник, то увидим, что в системе появился новый диск D:.

Создаем шару


В Проводнике на удаленном сервере создадим новую папку на только что подготовленном нами диске и назовем ее, например, Share. Снова откроем окно Диспетчера серверов. В левой панели расположена надпись Файловые службы и службы хранилища. Щелкнем на ней мышью, чтобы перейти к настройкам.



Откроется одноименное окно, в котором демонстрируются следующие оснастки:
Серверы содержит список серверов (в нашем случае один) и журнал событий;
Тома данные о логических томах, общих ресурсах, сведения о диске;
Диски данные о зарегистрированных в системе дисковых накопителях;
Пулы носителей список доступных пулов хранения, по умолчанию пустой;
Общие ресурсы сведения обо всех настроенных на сервере общих ресурсах (шарах);
iSCSI сведения о виртуальных дисках iSCSI;
Рабочие папки данные о настроенных на сервере синхронизируемых Рабочих папках

Перейдем в раздел Общие ресурсы, и в расположенном сверху меню Задачи выберем пункт Новый общий ресурс.



Запустится Мастер создания общих ресурсов. В первую очередь нужно выбрать из списка подходящий профиль общей папки. Нам подойдет вариант Общий ресурс SMB быстрый профиль, поскольку он позволяет предоставлять доступ к файлам на компьютерах с Windows и не требует настройки дополнительных параметров.



Нажимаем Далее. В следующем окне нам предложат выбрать папку для создания общего ресурса. Устанавливаем переключатель в позицию Ввести пользовательский путь, жмем Обзор и выбираем созданную нами ранее папку Share. Снова жмем Далее.



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



По нажатию Далее система продемонстрирует стандартный для Windows Server список разрешений на доступ к папке, согласно которому полные права на чтение и запись имеет только пользователь с правами Администратора. Нажмите в окне Мастера на кнопку Настройка разрешений, затем Добавить -> Выберите субъект, в нижнем поле введите Все (без кавычек), нажмите Ок и установите флажок Полный доступ. Нажмите Применить, затем Ок.

Осталось только нажать в окне Мастера создания общих ресурсов кнопку Далее и Создать. Выбранная нами папка появится в панели общие ресурсы.



Траблшутинг


Теперь, казалось бы, мы можем обращаться к этой папке прямо из Проводника. Для этого набираем в адресной строке \\ip-адрес-нашего-сервера, вводим имя и пароль Администратора, и видим нашу расшаренную папку с тем именем, которое мы задали ей на этапе настройки. Можно пользоваться шарой? Хренушки. Отказано в доступе. Винда не была бы виндой, если бы все было так просто. Самый простой способ избавиться от этой ошибки такой.

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



Если сетевое обнаружение никак не хочет включаться, делаем следующее: в панели поиска набираем без кавычек Службы или services.msc, и принудительно запускаем следующие службы (если они еще не запущены):
DNS-клиент (DNS Client)
Обнаружение SSDP (SSDP Discovery)
Публикация ресурсов обнаружения функции (Function Discovery Resource Publication)
Узел универсальных PNP-устройств (UPnP Device Host)

Для каждой из этих служб настоятельно рекомендую включить автоматический запуск. Все? Теперь-то мы можем использовать общую папку? Нет!

Запускаем на сервере Проводник, находим в нем нашу расшаренную папку. Щелкаем на ней правой клавишей мыши, в контекстном меню выбираем пункт Свойства и открываем вкладку Безопасность. Выбираем щелчком мыши пользователя Все и нажимаем на кнопку Изменить. Устанавливаем флажок Полный доступ, жмем Применить и Ок.



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



Неужели квест закончен и мы можем пользоваться нашей шарой? Как бы ни так! Ведь это операционная система Windows Server 2019, в которой безопасность стоит на первом месте. Поэтому при попытке обратиться к серверу из Проводника на локальном компьютере мы, скорее всего, увидим ошибку Вход в систему не произведен: выбранный режим входа для данного пользователя на этом компьютере не предусмотрен.



На этом этапе кое-кто отчаивается и идет покупать платный аккаунт в Dropbox за $9.99. Но мы сильны духом, любим секс, а потому продолжаем эксперименты. Вновь открываем Удаленный рабочий стол на сервере, вводим в поисковую строку слово Администрирование (без кавычек) и нажимаем Enter. В окне Администрирование выбираем Локальная политика безопасности -> Локальные политики -> Назначение прав пользователя -> Отказать в доступе этому компьютеру из сети Гость. Дважды щелкаем на этой строке мышью и удаляем Гостя из списка.



Все! Аллилуйя! Вот теперь, после всех этих плясок с бубном общий доступ к папке будет наконец открыт, и мы получим возможность насладиться всеми чудесными возможностями Windows Server 2019. Как минимум, сможем сохранять в шаре файлы. Для пущего удобства можно подключить удаленную папку в качестве сетевого диска. Для этого:

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



При первом подключении к диску потребуется ввести логин и пароль Администратора сервера. В дальнейшем параметры учетки будут подтягиваться автоматически.

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

Квотирование и Рабочие папки


При желании в Диспетчере серверов можно настроить квотирование, то есть, запретить пользователям создавать в общей папке файлы больше заданного объема. Еще там есть занимательный инструмент Рабочие папки. Фактически, это та же сетевая шара, только с автоматической синхронизацией, как в Dropbox или у Яндекс.Диска. Файлы в Рабочей папке хранятся на сервере и остаются там даже после удаления файлов на устройстве пользователя. Подробнее почитать о них можно , я же не буду описывать технологию настройки Рабочих папок, поскольку она в целом схожа с настройкой обычной сетевой шары, которую мы подробно рассмотрели в этой статье.



Подробнее..

Перевод Кунг-фу стиля Linux удобный доступ к справке при работе с bash

26.11.2020 16:14:32 | Автор: admin
В наши дни редакторы кода часто предлагают программистам помощь или справочные сведения, относящиеся к тому, что вводится с клавиатуры. Это может быть всё что угодно от списка коротких вариантов автозавершения ввода до шаблонов для ввода больших фрагментов кода. Если вы уже написали миллион программных строк на некоем языке, то такая вот помощь может вам мешать. Но если вы пишете программы лишь от случая к случаю, вам это может очень пригодиться. Я пользуюсь Linux уже много лет, но понимаю, что есть люди, которые не работают в этой ОС ежедневно. А учитывая растущую популярность Raspberry Pi, учитывая распространённость Linux-серверов, и то, что в Windows 10 появилась возможность работать с bash, оказывается, что всё больше и больше людей пользуются командной оболочкой Linux лишь время от времени. Можно ли как-то облегчить жизнь таким людям? Полагаю, что можно. Специально для этого я написал небольшой скрипт, который называется bashelp.



На самом деле, в сфере справочной информации по Linux-командам есть кое-что хорошее и кое-что плохое. Хорошо здесь то, что в Linux уже давно имеется встроенная команда, позволяющая получать справочные сведения. Это man (сокращение для manual руководство). Если говорить о плохом, то можно отметить, что для получения справки нужно оставить текущее дело и выполнить команду man.

Существуют графические интерфейсы для man, вроде yelp, показанного на следующем рисунке.


Графический интерфейс для man

Для просмотра man-страниц можно даже пользоваться веб-браузером. Но ни один из этих способов получения справочной информации не связан с тем, что пользователь вводит при работе с командной строкой. Для получения справки нужно открывать новое окно, искать там материалы, а потом возвращаться к тому, что делалось до этого. Такое положение дел заставило меня задуматься о том, как создать нечто вроде встроенной системы контекстной помощи для bash.

При создании подобной справочной системы нужно, как и в случае с настройкой автозавершения ввода по нажатию клавиши Tab, учитывать две вещи: во-первых нужна функция, выводящая справочные сведения, во-вторых нужно некое средство, заставляющее readline в нужный момент вызвать эту функцию. Моя система представлена скриптом bashelp.sh, который решает обе вышеописанные задачи. Но он работает только тогда, когда задано значение переменной $DISPLAY, что указывает на то, что в настоящий момент используется графический терминал. В Mac, кстати, работа с графическим интерфейсом устроена не так. Поэтому если вы хотите пользоваться этим скриптом на Mac-компьютере, вам понадобится внести в скрипт некоторые изменения. Если вы сделаете это, и то, что у вас получится, заработает, я с удовольствием взгляну на ваш PR в репозиторий проекта или на форк проекта.

Скрипт позволяет задать клавиатурную команду, вызывающую справку. Я выбрал сочетание клавиш CTRL+Y. Команда bind, используемая в скрипте, полагает, что это сочетание клавиш выглядит как \C-Y. Найти эту команду можно в верхней части кода скрипта. Вы можете выбрать другое сочетание клавиш. Там есть и ещё некоторые настройки. Например, man-справку можно открыть в отдельном окне терминала, или можно запустить графический вариант man. Подробности о настройке скрипта ищите в файле readme.

Сама функция вывода справки устроена очень просто. Если у вас нет графической системы X она работать не будет (опять же обратите внимание на $DISPLAY). Она ожидает, что данные от readline будут в $READLINE_LINE и $READLINE_POINT. Если данных нет скрипт завершает работу. После этого функция берёт первое слово из строки до пробела, а после этого обрабатывает все опции, что позволяет ей открыть справку в том виде, в котором нужно пользователю.

Конечно, это лишь один из примеров того, что можно сделать, вмешиваясь в работу readline. Это полезный приём, который пригодится тем, кто пользуется bash-скриптами или пишет их.

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

Применяете ли вы какие-нибудь особые приёмы при работе со справочными материалами по командам Linux?



Подробнее..

Как выбрать Service Desk для управления мобильными сотрудниками? И на что обратить внимание при внедрении?

17.11.2020 16:15:10 | Автор: admin

Статья рекомендуется к прочтению тем, у кого болит вопрос управления и контроля персонала на выезде, а также тем, кто собирает полезную информацию перед внедрением FSM или Service Desk системы для управления мобильными сотрудниками.

Приветствую всех. С кем не знаком - Андрей Балякин: 7 лет в сервисном бизнесе, 20 лет в ИТ. Предприниматель. Последние несколько лет - CEO проекта HubEx (ИТ платформы автоматизации выездного обслуживания и управления сервисными процессами).

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

Цель публикации - собрать мнения и всесторонний опыт тех, кто внедрил какие-либо системы для управления выездными сотрудниками в своей компании и готов поделиться опытом с остальными.

Для начала давайте определимся, о чем пойдет речь: ИТ сообщество подобные системы часто называет ITSM или Service desk с приложением для мобильных сотрудников. В англоязычном мире под этот класс систем есть отдельный термин: Field Service Management или сокращенно - FSM (не путать с Workforce management). В переводе это звучит как управление полевым сервисом, но более понятным будет - управление выездным обслуживанием или управление мобильными сотрудниками.

Чем я поделюсь:

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

  2. Расскажу о различиях продуктов класса управление выездным обслуживанием

  3. Обсудим, для каких компаний какие типы систем предпочтительнее

  4. Объясню, на что следует обращать внимание перед внедрением решения для управления мобильным персоналом в своей компании

  5. Приведу пример сервисного процесса и его стадий для более глубокого понимания требований к системе, а также удобной настройки процесса по шаблону, если систему вы уже выбрали

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

Чтобы избежать субъективных мнений по основным вопросам и принципиальным отличиям различных систем управления выездным обслуживанием, начну с мнения аналитического агентства Gartner. Он недавно выпустил свежую публикацию на тему Field Service Management-а в дополнении к обновлению магических квадрантов. Вот ссылка на статью для англо-понимающих: https://www.gartner.com/doc/reprints?id=1-2438LY1F&ct=200903&st=sb

Что говорит уважаемый Gartner?

Во первых:

Решения по управлению мобильными сотрудниками делятся на 2 категории, а при выборе следует учитывать следующие моменты:

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

  1. мировой лидер в классе (имеется в ввиду следующее: берем SAP, Microsoft, Oracle и т.п. мировых лидеров + стартуем дорогостоящий проект адаптации/доработки/внедрения и пилим, пилим, пилим. Стоимость таких проектов, в среднем, от 200k$ до 900k$ по РФ)

  2. выбираем нишевое отраслевое решение от локального вендора.

Gartner, советует: Выбирайте подходящее решение, исходя из вашей сферы деятельности, сложности и объема требований, а также необходимости кастомизированной настройки и готовности к доработкам.

Получается, что первый вариант - дорого, богато, никаких компромиссов. Будет сделано именно то, что нужно вам (тут все часто зависит от зрелости команды внедрения и готовности бизнеса к долгострою и серьезным инвестициям) . Второй - значительно меньшие инвестиции и возможность в разумные сроки закрыть 80% функциональных требований. Но именно 80, не 100%!

Во вторых:

Gartner делит вендоров (разработчиков) систем управления выездным персоналом (FSM-систем) на три категории.

Appointment-Centric: в основе лежит управление заявками и расписаниями сотрудников

Признаки: у сотрудников множество поездок/заявок в день. В этом случае, при выборе системы, наиболее важным для компании будут возможности системы удобно управлять заявками и оптимизировать расписания сотрудников.

Equipment-Centric: в основе лежит выездное техническое обслуживание и ремонт оборудования

Признаки: компания специализируется на выездном обслуживании оборудования, технические специалисты имеют узкую специализацию. Для них важно оперативно получать информационную поддержку и помощь. Gartner обращает внимание на то, что такая поддержка и сопровождение выездных специалистов с узкой специализацией наиболее приоритетная задача для компании.

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

Для примера:

  1. Приложение мобильного сотрудника должно помогать ему получить необходимую документацию по ремонтируемому оборудованию, технологические карты или коды ошибок

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

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

Outcome-Centric: для компаний, использующих модель Equipment-as-a-Service (Оборудование, как сервис/услуга)

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

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

Для таких компаний часто важнее всего быстрая диагностика оборудования и получение данных о работе (поломках) онлайн.

Что требуется от ИТ-системы в этом случае?

  1. Наличие мобильного приложения, чтобы в режиме реального времени получать данные мониторинга оборудования, в том числе на выездах, и оперативно принимать меры

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

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

Ticket-centric: сервис деск на базе ITSM service desk/service management систем, расширенный мобильным приложением для выездных сотрудников и модулем управления расписаниями.

Фактически получаются системы вида Appointment-centric (ориентированные на работу с заявками), но, в отличии от последних, обычно имеющие ряд ограничений. Возможности этого класса решений обычно упираются в возможности ITSM систем, сделанных для ИТ и работающих в рамках ITIL практик. Как итог - выездным сервисным сотрудникам оказывается неудобно работать по процессам ИТ, у них своя специфика, отличная от ИТ-сервиса.

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

Appointment-centric: в основе лежит управление заявками и расписаниями сотрудников

Сотрудник и расписание вынесены в начало схемы намеренно, так как именно эти сущности определяют логику работы систем данного класса. Продвинутые Appointment-centric FSM системы позволяют удобно планировать загрузку персонала с учетом расписаний работы объектов. Они учитывают сменный график работы сотрудников, автоматически планируют и оптимизируют расписания, динамически перераспределяют заявки в случае форс-мажора.

Equipment-centric: выездное техническое обслуживание и ремонт оборудования

В начало процесса добавляется оборудование с иерархией до узлов и агрегатов, когда необходимо.

Все заявки привязываются к оборудованию. Выполнение плановых работ также привязывается к оборудованию.

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

Вся аналитика ремонтов, обслуживание и устранение неисправностей собирается вокруг оборудования. Фактически это получается FSM по модели ТОиР.

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

Equipment-Centric системы управления выездным обслуживанием для большинства компаний могут заменить ТОиР решения. Такой вариант подходит в тех случаях, когда в процессе деятельности компании ремонты осуществляются мобильными сотрудниками или подрядчиками, а базовых ТОиР функций вполне достаточно для контроля обслуживания и ремонтов оборудования.

Outcome-centric: в основе лежит оборудование как услуга

Тут мы видим обвязку к упрощенной модели Equipment-centric FSM. Создание вложенных заявок на нескольких сотрудников обычно не требуется, однако добавляется обязательное условие получения информации о работе оборудования. Например, интеграция решения, по управлению выездным персоналом с IoT или мониторинговой системой, сообщающей о состоянии и работоспособности оборудования.

Outcome-centric: оплата за результат или достижение согласованных показателей

Например, клиент платит абонентскую плату за достижение показателя бесперебойной работы оборудования. Если уровень доступности ниже согласованного контрактом SLA - плата снижается или отсутствует вовсе.

Ticket-centric: в основе лежит работа с заявками. Своего рода сервис деск, расширенный приложением для мобильных сотрудников

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

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

Еще один тип систем, которые пытаются использовать ряд компаний при реализации задачи управления выездными сотрудниками - настройка CRM под задачи FSM.

Какие функции вам точно потребуется или почему не стоит заменять специализированные решения на всемогущие CRM

Почему я добавил CRM? Причины две:

  1. Среди ИТ-решений по управлению мобильными специалистами иногда встречается такое понятие как CRM для выездных сотрудников. По факту это то же самое FSM-решение с урезанной функциональностью или Service desk с примитивным мобильным приложением. Осмелюсь предположить, что CRM в названии присутствует по простой причине: FSM у нас в России не раскачена, такие запросы пользователи не ищут, а в поисковиках светиться нужно. И чем проще и понятнее ты назовешься - тем лучше. А CRM, как известно знают все

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

Заявка хоть и похожа на воронку со стадиями, которые можно как-то назвать, но в CRM нет и половины функций, которые требуются компаниям с мобильными сотрудниками. Например:

  1. расписания сотрудников и объектов обслуживания в связке с специализаций и географией, позволяющие системе автоматизировано распределять заявки

  2. учет оборудования и привязки к нему заявок / выполняемых работ

  3. GPS-контроль персонала

  4. ТОиР-модуль для работы с плановыми заявками и с возможностью создавать группы заявок по типам объектов, оборудования, видам работ и других сущностей системы

  5. история обслуживания

  6. расчет плановых сроков закрытия заявок согласно SLA с заказчиком

  7. специализированные инструменты для экспресс-подачи заявок заказчиком

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

  9. справочник работ и услуг

  10. иерархия объектов обслуживания, как и самих объектов с гео-привязкой на местности

  11. оффлайн режим в мобильных приложениях

  12. расчет стоимости выполненных работ и оказанных услуг через приложение

  13. возможность администрирования складов, учета складских запасов и остатка материалов, указания в заявке использованных материалов со склада

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

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

  • Сервис деск с мобильным приложением для выездных сотрудников дают больше возможностей. Однако стоит внимательно оценить их возможности при выборе подходящей системы под задачи компании.

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

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

На этот раздел крайне рекомендую обратить особое внимание всех, кто планирует автоматизировать работу выездных сервисных сотрудников.

Для удобства структуру сделал в виде чек-листа, заполнив который по выбранным решениям можно сделать осознанный вывод: подходит решение или не совсем. Если подходит на 85% и больше - повод примерить.

Чек-лист для компаний, внедряющих FSM решение по управлению выездными обслуживанием: на что обратить внимание?

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

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

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

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

  • Найдите у себя в компании лидеров мнений.

  • Обсуждайте с ними новые процессы с самого начала.

  • Показывайте систему.

  • Дайте попробовать поработать и собирайте фидбэк.

  • Мотивируйте их на результат (премии по итогам проекта, слава и поощрения, кому что)

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

Итак, чек-лист по выбору FSM решения.

Отметьте те пункты, которые важны для вашей компании, и оцените по ним различные решения на рынке. У кого есть опыт в работе /внедрениях Service desk или FSM решений для управления заявками и работой выездного персонала: возможно я что-то упустил в списке, так что дополняйте в комментариях. Буду обновлять список. В итоге получим удобный чек-лист для тех, кто выбирает систему управления выездным обслуживанием.2

Сравнение возможностей

Требуется

(да/нет)

Система 1

Система 2

1.

Работа с заявками:

1.1

Возможность интеграции по входящим заявкам с системами заказчиков.

Чтобы диспетчеру не пришлось заводить все заявки вручную

1.2

Возможность загружать заявки пакетами.

Это часто требуется, когда заказчики, подающие заявки, обязуют подрядчика работать в своей системе и не дают возможностей для интеграции

1.3

Омниканальность по входящим обращениям

1.4

Возможность настраивать правила парсинга при импорте заявок через почту.

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

1.5

История изменения заявок с возможность просмотра кто, где, когда и что делал

1.6

Ролевая модель - возможность выдавать доступ и отображать только ту информацию, которая может быть доступна для сотрудника с данной ролью

1.7

Удобство работы со списком заявок, сортировка, добавление пользовательских полей, перемещение полей в списке, фильтрации - стоит попробовать самостоятельно

1.8

Сохранение быстрых фильтров - сколько сотрудников, столько и вариантов фильтрации.

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

1.9

Создание заявок по расписанию. Обратите внимание, что часто требуется не просто создавать заявки по определенному интервалу (каждый вторник, каждую 2 неделю, каждый месяц), но и за определенное количество дней до дня Х. Т.е. заявка должна появляться не в заданный расписанием день, а за Х дней или часов до него

1.10

Аналитика по заявкам.

Это отдельный тонкий вопрос, детально расскажу ниже

2.

Дочерние/вложенные заявки:

2.1

Дочерние заявки требуются тогда, когда ремонт или обслуживание могут проводиться разными сотрудниками в разное время. При этом требуется собирать статистику работ и управлять ремонтом, как мини-проектом: получили заявку, декомпозировали ее на несколько сотрудников, поставили в расписание и контролируем выполнение заявки

2.2

Полноценная работа с дочерними заявками как с родительскими заявками (не в форме чек-листа: получил заявку, выполнил, а полноценно с движением заявки по регламентированному процессу)

3.

GPS-контроль выездного персонала - важная функция при работе с мобильными сотрудниками

3.1

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

3.2

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

3.3

Возможность контроля путевых листов: сверка задекларированного пробега сотрудника с фактическим и расчетным

3.4

Возможность для диспетчера видеть на карте не только местоположение сотрудников, но и заявок, с возможностью их распределения на сотрудников в соответствии с их квалификацией и занятостью

3.5

История перемещений сотрудников в привязке к заявкам

ВАЖНО: для контроля недостаточно понимать, где находится сотрудник, важно знать что он делает: какую заявку выполняет или выполнял, на каком объекте и сколько времени. Это основная причина, почему без системы диспетчеризации заявок геотрекинг мало что дает

4.

Мобильное приложение выездных сотрудников:

4.1

Поддержка iOS и Android смартфонов. Одинаковые возможности приложений.

По опыту, неудобно, когда пользователи iOS и Android имеют разный функционал

4.2

Работа приложения сотрудника в офлайн

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

4.3

Встроенные чаты между исполнителем и диспетчером

4.4

Возможность опционально добавлять других сотрудников в чат

4.5

Разделение на чаты внутри компании и чаты с клиентами. Ценно, когда ваши заказчики могут подавать заявки через мобильное приложение клиента

4.6

Просмотр истории выполненных заявок по оборудованию (объекту) и истории ремонтов/обслуживания

4.7

Возможность добавлять к заявке не только фото, но и видео-файлы с описанием проблемы

4.8

Возможность переназначения заявки на другого сотрудника (для определенных ролей)

4.9

Добавление кнопок-действий в мобильное приложение без разработки

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

4.10

Расчет стоимости выполненных работ и автоматическое формирование акта выполненных работ в смартфоне с подписью пальцем или стилусом на экране

4.11

Возможность при помощи мобильного приложения взять оборудование на обслуживание (процесс онбординга нового клиентского оборудования в систему) и промаркировать объект или оборудование

4.12

Согласование заявок из смартфона

4.13

Возможность сделать комментарии обязательными при выполнении определенных действий

5.

Чек-листы

5.1

Возможность подать заявку по пункту чек-листа во время его заполнения

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

5.2

Возможность затребовать в чек-листе фото- или видео отчет

5.3

Запрет на добавление фото и видео из галереи - только из камеры. Это поможет предотвратить повторное использование фотографий и фальсификацию результатов

5.4

Фиксация места/даты/координат съемки фото и видео

5.5

Привязка чек-листа к оборудованию, объекту или услуге

Чек-лист по оборудованию

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

Чек-лист по объекту

Например вы можете регламентировать процесс выполнения заявок у конкретного заказчика на конкретном объекте

Чек-лист по работам

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

Чек-лист по сбору контролируемых параметров

Поможет зафиксировать параметры работы или какие-то показатели на объекте

5.6

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

6.

Работа с оборудованием и объектами обслуживания:

6.1

База данных установленного оборудования с иерархией

6.2

Пользовательские поля у оборудования

Например, для учета одного оборудования требуется: парт-номер, серийный номер, год выпуска. Для другого - цвет, срок эксплуатации, производительность и список подрядчиков на сервис. Все индивидуально

6.3

Привязка выполняемых заявок к оборудованию или объектам обслуживания

6.4

Возможность заполнить в мобильном приложении акт выполненных работ и получить подпись клиента на экране смартфона

6.5

Автоматизированный расчет стоимости выполненных работ в мобильном приложении при закрытии заявки

6.6

Возможность просмотра истории обслуживания по оборудованию

6.7

Группировка оборудования по типам (печи, кондиционеры и т.п.) для удобства аналитики

6.8

Принятие оборудования на обслуживание через мобильное приложение

6.9

Маркировка оборудования для безошибочной экспресс-подачи заявки клиентом (снижает количество ошибок и нагрузку на диспетчеров)

6.10

Привязка видов работ к оборудованию - какие работы можно выполнять на оборудовании и по контракту

6.11

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

6.12

Возможность создания контактных лиц в привязке к оборудованию для удобства работы мобильных сотрудников

6.13

Графики работы оборудования или объектов обслуживания

6.14

Признаки, находится ли оборудование на гарантии

6.15

Навыки или допуск, которым должен обладать сотрудник для назначения на ремонт

6.16

Чек-листы по оборудованию

6.18

Выбор сотрудников, ответственных за оборудования

Поможет назначать заявки на тех, кто знает и умеет ремонтировать этот тип оборудования

6.19

Импорт, экспорт, интеграции

6.20

Привязка к оборудованию QR или NFC-метки, которая позволяет удобно подать заявку, если промаркировано оборудование или объект заказчика

6.21

Иерархия оборудования и объектов: объект - оборудование - компонент и тд

6.22

Мобильность оборудования - возможность привязать геопозицию и перемещения гео-метки при перевозке оборудования с объекта на объект

7.

Функции CRM

7.1

Ведение карточек клиентов с реквизитами и платежной информацией (если необходимо выставлять счета)

7.2

Контактные лица

7.3

Возможность привязать к компании обслуживаемое оборудование

7.4

Опция приложить файлы/документы к карточке

Удобно для хранения прайс-листа или контракта в доступе для диспетчера или офисных сотрудников

7.5

Перечень стандартных реквизитов: сайт, почта и тд

7.6

Возможность вести заявки в разрезе заказчиков или объектов оборудования

7.7

Определите другие функции CRM, которые для вас критически важны, если вы планируете использовать FSM-систему и для контроля взаимоотношений с клиентами

8.

Работа с расписаниями

8.1

Распределение заявок в расписание сотрудников на карте

8.2

Управление расписанием в интерфейсе (drag&drop) с просмотром заявок с таблице расписаний или календаре

8.3

Отображение рейтинга сотрудников в расписании

8.4

Выбор рекомендуемых исполнителей (по компетенциям и навыкам)

8.5

Авто-распределение заявок в расписание по различным правилам

9.

Уведомления - какие способы нотификации персонала для вас важны?

9.1

SMS (дорого, но надежно)

9.2

PUSH

9.3

Уведомления в приложении

9.4

Нужно ли диспетчеру видеть, что сотрудник не подтвердил прием заявки и звонить ему

9.5

Требуется ли настраивать текст и логику уведомлений

10.

Автоматическое распределение заявок

10.1

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

11.

Настройка стадий заявок и логики перехода со стадии на стадию

11.1

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

Вот очень простой базовый процесс прохождения заявки на выездное обслуживание:

Вот такой базовый шаблон наш департамент внедрения разработал для того, чтобы настраивать для заказчиков HubEx типовые процессы прохождения заявок:

Далее, на данный процесс накладываются полномочия (что можно делать сотруднику с конкретной ролью на конкретной стадии, а что нельзя).

Дополнительно настраивается система уведомлений (кто что и когда должен получать при поступлении заявок на конкретные стадии или при просрочках / Опозданиях итп).

Аналитика: the last, but not least, как сказали бы англичане: последний по порядку, но не по значению.

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

Прежде отмечу, что важно иметь возможность видеть данные показатели в динамике, а также во всех разрезах, которые так или иначе присутствуют в системе, например в разрезе:

1. Периодов

2. Клиентов

3. Сотрудников

4. Оборудования

5. Объектов

6. Типам заявок

7. Типам работ

8. и т.д.

Оперативные показатели:

1. Кол-во открытых заявок

2. Кол-во не назначенных заявок

3. Кол-во заявок, не принятых в работу

4. Кол-во просроченных заявок

5. Кол-во заявок, по которым исполнитель опаздывает на объект

6. Кол-во заявок, которые истекают сегодня

7. Среднее время реакции диспетчера

8. Кол-во футбольных заявок, по которым исполнители несколько раз отказались от выполнения

Данные показатели предназначены, преимущественно, для диспетчеров или сотрудников, контролирующих назначение или исполнение заявок в срок.

Метрики для руководителей

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

Условно выделяемые нами показатели можно разделить на следующие категории:

Количественные:

  1. Кол-во созданных заявок за период

  2. Кол-во закрытых заявок за период

  3. Кол-во эскалированных заявок за период

  4. Кол-во закрытых в срок / не в срок заявок

  5. Кол-во отказов исполнителей по заявкам

  6. Динамика создания/закрытия заявок с графиком их сгорания

  7. Соотношение заявок по типу заявки

  8. Соотношения заявок по срочности

  9. Соотношение заявок по типу работ

  10. Соотношение заявок, созданных через разные источники (диспетчера, клиенты самостоятельно, через интеграцию со сторонними сервисами и др.)

  11. Кол-во обслуживаемых объектов / оборудования

  12. Кол-во клиентов

SLA показатели:

  1. Contract Uptime Rate % бесперебойной работы оборудования

  2. First Time Fix Rate - % выполненных заявок с первого посещения

  3. Repeat Visit кол-во повторных визитов на объект по одной и той же заявке

  4. Нарушения сроков разрешения заявок, указанных в SLA

  5. Оценки клиентов по выполненными работам

  6. Превышение фактического времени выполнения заявок относительно планового по типам работ

Временные показатели:

  1. Average Time to Fix среднее время выполнения работ исполнителями

  2. Average Time to Complete среднее время от создания до закрытия заявки

  3. Среднее время реакции диспетчера

  4. Среднее время принятия исполнителем заявки в работу

  5. Среднее время от создания заявки до назначения на исполнителя

  6. Среднее время от принятия заявки исполнителем до переведения в статус В пути

  7. Среднее время исполнителя на дорогу

Финансовые показатели:

  1. Выручка

  2. Прибыль

  3. Средний чек

  4. ТОП клиентов по выручке и прибыли

  5. Доля выполненных заявок по контракту и по сдельной схеме

  6. Service to Cash Time время от завершения работ исполнителем до поступления оплаты от клиента

  7. ABC анализ клиентов

Показатели по исполнителям

  1. Utilization Rate % рабочего времени исполнителей, которое было потрачено на работу и оплачено клиентами

  2. Tasks Per Person среднее кол-во выполненных заявок на одного исполнителя

  3. Отработанные сотрудниками часы

  4. Переработки сотрудников

  5. Оценки клиентов по выполненным исполнителями работам

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

Итого

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

Шаги внедрения

  1. Определите, к какому подклассу должна относиться целевая FSM система для вашей организации: appointment-centric / equipment-centric / outcome-centric или ticket-centric.

  2. Найдите поддержку среди лидеров мнений в вашей организации

  3. Зафиксируйте цели внедрения системы и показатели, оцифровка которых крайне важна

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

  5. Сформулируйте требования к системе, воспользовавшись предложенными выше шаблонами

  6. Проанализируйте рынок решений с учетом типа FSM решения из п.1,

Удачи в нелегком, но важном и абсолютно верном начинании.

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

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

Заранее благодарю!

Подробнее..

Из песочницы Действительно ли полезен ML для снижения шума от алертов? Изучаем на примере одного метода

19.11.2020 16:18:00 | Автор: admin


Предыстория


Последние пару лет рынок систем мониторинга будоражила аббревиатура AIOps. Все вендоры начали гнаться за использованием искусственного интеллекта в своих сложных и дорогих системах. Термины root cause analysis, correlation, ML-tools, anomaly detection, incident prediction, noise reduction основательно и, наверное, уже навсегда поселились на маркетинговых материалах и сайтах различных систем мониторинга.


Как мы знаем, рекламные буклеты одно, а инженерные будни другое. Наверное, многие сталкивались с ситуацией, когда обещания продавцов тех или иных технологических новинок сталкивались, как Титаник с айсбергом, с практикой внедрения, особенно в сложном ИТ-окружении больших компаний. Поэтому я изначально смотрел с большим скепсисом и не разделял ажиотажа вокруг этой темы. Тем более, когда есть такие железобетонные решения как Zabbix, Prometheus и Elastic. Но хайп хайпом, скепсис скепсисом, а мы все-таки инженеры и должны все проверять и изучать на практике, а не задаваться вопросом верить/ не верить в magic button от именитых вендоров и многообещающих стартапов. И вот, после очередной презентации от интегратора и обещаний за немаленькие деньги рая на нашей грешной земле инженеров эксплуатации нас собралась небольшая инициативная группа, которая решила пощупать, что все-таки из себя представляет эта магия искусственного интеллекта и машинного обучения в нашей практике. Таким образом, родились материалы и даже небольшой pet-проект, которыми я бы хотел поделиться с вами.


Жизненная проблема служб мониторинга


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


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


Для данной статьи далее приводятся результаты наших наработок на реальных открытых данных. В качестве таких данных мы взяли HTTP-проверки сайтов основных ритейлеров. Самая яркая выборка получилась у Магнита, отдельное ему спасибо за это. Кстати, на downdetector его нет, а, наверное, стоило бы добавить ;)


Классика


Для нашего примера берем интервал времени
2020-10-14 14:00 +03:00 минус 38 часов (ранее данных не было), т.е. [2020-10-12 23:00:00 +03:00 2020-10-14 14:00 +03:00]. За этот период всего прошло проверок: 3612.


Если брать стандартный алгоритм оповещения по порогам (threshold), который формирует оповещение, если предыдущее значение было 0, а текущее 1, то на такой выборке сформировалось бы 179 оповещений. При этом имеем самую высокую оперативность в оповещении о проблемах (см. рис. 1: распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным оповещения
).


Рис.1Рис. 1. Распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным оповещения.


Если использовать алгоритм вычисления порога данных, при котором оповещение приходит только в случае проваленных подряд 3-х проверках, то по данной выборке сформировалось бы 44 оповещения (см. рис. 2). При этом задержка алерта уже составит как минимум 4 интервала проверки. Также мы рискуем напороться на проблему отсутствия алерта для ряда вида 0110010011101010, которую, можно частично решить, установив дополнительный триггер на % проваленных за период времени (обычно 1 час), что опять-таки приведет к потере оперативности.


Рис.2Рис. 2. Распределение оповещений по 3-м проваленным подряд проверкам. Синим показаны проваленные проверки, красным оповещения.


Таким образом классические алгоритмы заставляют выбирать: либо флуд-поток алертов, либо потеря оперативности. Причем при ограниченных ресурсах флуд-поток зачастую приводит к не меньшей потере оперативности, чем при сложных настройках триггеров. Осталось посмотреть, что нам в такой ситуации могут предложить методы AI/ML.


А что ML?


Прежде чем пойдем дальше, сразу бы хотелось оговориться, что мы не являемся Data Scientist и перед нами не стояла задача выбора оптимального метода. Наша задача заключалась в том, чтобы, во-первых, найти любой метод, который соответствовал 3-м критериям:


  1. Давал бы практическую пользу. В нашем случае реально бы снижал количество алертов, при этом не пропуская проблемы.
  2. Был бы реализуем без серьезных вычислительных затрат, и, соответственно, его можно было бы встроить в пайплайн обработки собираемых метрик.
  3. Результаты, получаемые на выходе, можно было бы "качественно" интерпретировать и предсказать. Т.е. по сути метод должен быть достаточно простым и хотя бы "на ощупь" понятным без глубокого погружения в теорию вероятности, нечеткую логику и прочие радости высшей математики, частично подзабытые с университетской скамьи.

В нашем случае таким методом стал DetectIidSpike из библиотеки ML.NET. Основная идея данного метода: проверить укладывается или нет каждое новое значение на временном ряде в существующую выборку. Если не укладывается, то обозначить такое значение как аномалию. Другими словами для каждого нового значения проверяется "нулевая" гипотеза и если она подтверждается, то детектируется аномалия. После чего новое значение переобучает модель.
Отсюда очень важным для нормальной работы метода DetectIidSpike являются его два параметра:


  • confidence достоверность обнаружения аномалии в диапазоне [0, 100]. Чем больше значение, тем по сути шире полоса и, соответственно, тем больше значений будут восприниматься, как нормальные;
  • pvalueHistoryLength размер скользящего окна для вычисления p-value. Данный критерий как раз-таки используется в алгоритме для подтверждения "нулевой гипотезы", она же аномалия.

Теперь посмотрим, как данный алгоритм работает на практике. В рассматриваемом примере у нас HTTP-проверки сайтов, т.е. на выходе имеем единицы и нули. Для нашего алгоритма это вот не совсем подходящий материал. Здесь желательно иметь дело все-таки не с бинарными значениями. Для этого мы применили агрегацию данных по временным интервалам, т.е. превратили нашу последовательность из нулей и единичек на интервале 5 мин в число: отношение проваленных проверок к общему количеству проверок в этом интервале. Здесь велико было искушение взять просто количество проваленных, но это в корне неправильно, т.к. соседние интервалы могут отличаться по количеству проверок. Это может происходить как по причине динамических настроек проверок (например, при проблеме чаще идут проверки), так и по банальной причине задержек в проверках и пограничных "конфликтах", когда проверки попадают в соседние интервалы.


После этих подготовительных операций мы потоково направляем получаемые данные в наш прототип детектора аномалий в виде заданий. Стратегия запуска задания заключается в том, чтобы загрузить модель, рассчитанную в предыдущем раунде проверок, проверить является ли значение пиком (аномалией), провести дообучение модели полученным значением и сохранить измененную модель обратно на диск (или в память). Для этого наш планировщик раз в 5 мин формирует список заданий на вычисление в детекторе аномалий. Агенты, подключенные к планировщику по websockets протоколу, получают задания и выполняют их. На выходе мы имеем аномалии и оповещения, а сама система агентов очень легко масштабируется (у нас kubernetes реплики).


На приведенной выборке при настройках алгоритма (confidence: 95, pvalueHistoryLength: 5), мы в итоге получили 36 аномалий. Следует учитывать, что аномалией считается также резкое снижение количества проваленных проверок, т.е. за аномалии принимается восстановление работоспособности. Отфильтровав сообщения о восстановлении, имеем итоговые 24 оповещения. (Кстати, метод в библиотеке имеет соответствующую настройку).


Рис. 3Рис. 3. Аномалии и проваленные проверки (confidence: 95, pvalueHistoryLength: 5) Синим показаны относительные значений проваленных проверок, красным оповещения


Как видно из графика (рис. 3), при недостаточном уровне обучения модель генерировала большое количество аномалий вначале, которое значительно сократилось на последующем интервале после достаточного обучения. А также, что имеет первостепенное значение, не были упущены практически никакие проблемы и полученный детектор аномалий достаточно оперативно реагировал на возникающие провалы (закрашенные области).


Для сравнения на рис. 4 приведен результат работы модели со скользящим окном pvalueHistoryLength=12 и достоверностью confidence: 98. Здесь результат: 14 аномалий.


Рис. 4Рис. 4. Аномалии и проваленные проверки (confidence: 98, pvalueHistoryLength: 12)


Краткий вывод


Таким образом, применяя метод DetectIidSpike нам удалось снизить количество оповещений практически в два раза (24 против 44) по сравнению с проверкой на 3 подряд проваленные проверки, и в 7,5 раз (24 против 179) с однократным трешхолдом. При этом, самое главное, не теряя в качестве и оперативности. А это говорит нам о том, что методы ML могут нам действительно на практике помочь в задачах мониторинга. По крайней мере, приведенный метод точно :)


P.S.: Если у вас есть идеи или конкретные методы ML, которые вы опробовали для решения проблемы флуд-алертинга, пишите в комментариях. Будет интересно попробовать.


P.P.S.: Ниже приведу еще несколько скриншотов из нашего pet-проекта с реальными данными проведенных проверок и сгенерированных аномалий. Можете посмотреть насколько эффективно или неэффективно (for whom how) работает алгоритм (желтый кружок аномалии на выбранном интервале).


Несколько еще интересных скриншотов



Подробнее..

Внедрение CICD в чем основная задача пайплайна и как сделать лучше жизнь разработчиков

26.11.2020 04:22:27 | Автор: admin


О своём опыте построения пайплайнов, правильных и неправильных подходах к CI/CD, здоровых профессиональных конфликтах и реализации GitOps в неидеальном мире рассказывают спикеры курса Слёрма по CI/CD Тимофей Ларкин и Александр Швалов.


Кто говорит


Тимофей Ларкин
Руководил направлением автоматизации в дирекции BigData компании X5 Retail Group, строил платформу для разработки и хостинга продуктов. Сейчас работает платформенным инженером Тинькофф.


Александр Швалов
Инженер Southbridge, настраивает и сопровождает проекты на Kubernetes. Помогал настраивать CI/CD как для небольших, так и для крупных компаний. Certified Kubernetes Administrator.


Почему тема настройки CI/CD до сих пор остаётся актуальна? Почему до сих пор все не научились это делать?


Т: Я думаю, по той же причине, по которой уже одиннадцать лет существует слово DevOps, но некоторые компании и коллективы только-только запускают так называемую DevOps-трансформацию. По той же причине, что всегда есть отстающие, которые пока в группе Low Performеrs. Не все ещё научились. Не всем это вдруг стало нужно, не все так быстро разрабатывали внутри себя технологическую экспертизу.


То есть дело не в том, что тема сама по себе невозможна для реализации, а в том, что просто кто-то ещё последовательно до неё не дошёл?


Т: Да, всё так.


А: Я добавлю, что есть некоторые компании, стартапы, где два человека, допустим, сидят, и им пока не нужен CI/CD. Может быть, они о нём знают, но пока без него обходятся. И внедрение это должно быть на каком-то этапе, когда проект вырос до точки, где это необходимо. Тогда это принесёт больше плюсов, чем минусов. Когда есть только один талантливый программист, ему намного быстрее будет разрабатывать без CI/CD. Ну, и да, отсталость некоторых проектов. Я сам работаю с клиентами, и у них есть сайты с большой посещаемостью, куда они заходят и в середине рабочего дня вешают заглушку и начинают править код. Прямо на продакшене.


Какие это проекты?


А: Да просто интернет-магазины. Небольшие, естественно. В больших очень критичны простои. Там используют серьёзные технологии. А небольшие может, не слышали, может, им это неинтересно. Мы иногда рассказываем, что и как можно настроить, но без особого энтузиазма воспринимают. Мол, старое работает, и ладно.


До вопроса внедрения мы ещё дойдём. Расскажите о своём опыте построения CI/CD, что это были за проекты?


Т: Я около двух лет назад пришёл в X5 Retail Group как, на тот момент, единственный сотрудник нового подразделения, и на мне висела задача построить платформу для разработки, чтобы разработчикам дирекции больших данных было, где собирать свой код и где его запускать. Там достаточно много разных проектов. Какие-то более будничные: прогнозирование оптимальных цен, оптимальных промо-акций (вроде скучное, но приносит прибыль). И что-то более хайповое, вплоть до проектов по компьютерному зрению.


Технологии были разные. В основном для бэкендеров это Java, для фронтендеров это React. Ну, и для дата-сайентистов Python (Anaconda, Jupyter Notebook и тому подобное). Я должен был создать для них эту самую платформу разработки. То есть, CI/CD-серверы (у нас был GitLab), Kubernetes заставить всё это работать в связке и помочь продуктовым командам начать этим эффективно пользоваться.


Два года назад это началось и? Процесс завершился?


Т: На сегодняшний день я уже в X5 не работаю, но там ребята уже активно развились, очень хорошо освоились. Естественно, дирекция больших данных сейчас и то, что было два года назад это совершенно разные вещи. По количеству рост сотрудников, наверное, раз в 5-6. Ну, это была очень молодая дирекция на тот момент. Она очень быстро росла. И по компетенции, по парку серверов на этой рантайм платформе, по всему прочему рост был на порядки.


И люди тоже очень сильно компетенций набрались. Как я говорил, тогда я был единственным сотрудником отдела, а сейчас там примерно 10 человек. И были какие-то измеряемые успехи. Я воспроизводил исследование Ускоряйся, которое лежит в основе методики ежегодных отчётов State of DevOps, и по результатам этого исследования в масштабах одной только дирекции успехи были.


Александр, какой у вас опыт?


А: У меня опыт построения CI/CD первый был на третьем или на четвёртом потоке Слёрма, где я участвовал в качестве студента. Ведь Слёрм изначально задумывался как средство обучения сотрудников Southbridge, а я работал в Southbridge и как раз на одном из потоков плотно познакомился с CI/CD. До этого у нас было несколько клиентов с не совсем правильными подходами к CI/CD, а на обучении я увидел такой конкретный, цельный пример, и потом он мне очень пригодился.


У нас пришел клиент, ему нужно было мигрировать из Docker Swarm в Kubernetes некий стек и плюс распилить монолит. Там были уже несколько контейнеризованных микросервисов и плюс был монолит, который разработчики пилили и добавляли микросервисы, и вот это все мы заворачивали в Kubernetes. Поэтому туда я взял пример нашего CI/CD из Слёрма. Он простенький, но вполне себе рабочий. И в итоге мы дошли до того, что последние микросервисы разработчики деплоили уже сами, без нашего участия. Мы всё построили и отладили, а дальше они уже сами всё по шаблонам делали.


Если по этапам описать проделанную вами работу, в чем она заключалась? Как вы дошли от нулевой точки до момента, когда команда уже сама могла что-то делать?


А: Сначала мы адаптировали практически вручную то, что уже было в Docker Swarm микросервисы. Потребовался небольшой допил конфигурации. Плюс, helm-чарты написали первые. Использовался Kubernetes. Helm 2 на тот момент ещё был популярен. Ну и GitLab CI. После этого разработчики задавали множество вопросов, иногда делали не так, как мы задумывали. Мы поправляли их. У нас не было прямо тесной связи, мы иногда приходили и советовали, где как лучше сделать, чтобы работало. Таким путем проб и ошибок пришли к тому, что они теперь без нас отлично справляются.


До этого вы упомянули неправильные подходы. Что это было?


А: В целом неправильный подход для мелких проектов, наверное, оправдан. Потому что там не было CI-инструмента. У нас в курсе будут описаны некоторые уже устоявшиеся инструменты (online, self-hosted-решения). А там было проще некуда: задание по расписанию, git pull из репозитория с кодом. Буквально каждые две минуты он делает git pull. И когда разработчик в нужную ветку пушит изменения, он понимает, что это попадёт на продакшн. Т.е. через вот этот промежуток времени 1-2 минуты скрипт сработал, и всё попало на продакшн. Разработчику не нужно было самому ходить. Это такой небольшой пример CI/CD. Естественно, о тестах говорить не приходилось, всё было на совести разработчика.


Какие проблемы могут возникнуть при таком подходе? Ошибки?


А: Да, плюс откат. Если мы из этой ветки пушим постоянно, то чтобы откатиться, нужно будет в ту же ветку запушить уже более поздним коммитом нужную версию, уже исправленную. А не вернуться к предыдущему коммиту или предыдущему релизу/тегу.


Т: Тут еще, понимаете, это очень здорово работает, пока там действительно стартап из двух человек. И один только финансами занимается, а кодит только второй. Зачем ему тогда сильно следить за качеством своего кода? Зачем ему выстроенный CI/CD процесс? Он и так отлично знает, что у него где лежит. Проблемы начинаются, когда такую модель работы переносят на командную разработку, и там есть 2-3-4 сеньора, которые всё отлично знают, но никто не может начать с ними работать, потому что они не столь ответственно относились к качеству кода, не запускали тесты. Вроде и так всё понятно, но всегда тяжело учесть, что придёт человек со стороны а в больших компаниях это постоянно случается которому будет сложно объяснить, что тут вообще происходит. Цель CI/CD не просто автоматизировано допихать код до продакшена, но и следить за его качеством.


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

Если пайплайн просто собирает как-нибудь код и потом деплоит его, мы не знаем, что, собственно, задеплоили. Нормально или фигня. Может, там десять релизов уже, и каждый всё больше ломал наш код.


А как построить такую систему? Нужно, чтобы разработчики договорились о стандартах: мы все согласны, что вот так делаем, а вот так не делаем?


Т: Да, нужно прийти к соглашению, что мы считаем плохим/хорошим, как мы будем делать. Но в целом, это спор ни о чем. Не так важно, до чего вы договоритесь у вас будут табы или пробелы. Это все второстепенно. Выберите уже что-нибудь. Это лучше, чем ничего. В этом плане Golang такой интересный пример. Он не стал давать разработчикам волю самим выбирать, какое будет соглашение о качестве. Он просто сказал: Ок, у нас отступы табами, табы шириной 8 символов. И всё, не колышет. Это встроено прямо в утилиты самого Golang. Есть такое высказывание: Все его ненавидят, но при этом он самый лучший. Потому что хоть какой-то стандарт есть. Встроить проверку соответствия кода выбранным стандартам в пайплайн это буквально две строчки.


Как обеспечить контроль выполнения стандартов?


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


Значит, есть несколько таких ступенек?


Т: Да. Всегда принцип 20/80. 20% усилий дают 80% успеха.


А: Тут упомянули проверку кода. Это достаточно важно, и многие инструменты содержат в своём названии как раз CI. Travis CI, GitLab CI. И это очень важно проверить и программиста носом натыкать, это экономия труда тестировщиков. Может, потом код скомпилируется, запустится, даже будет первое время выглядеть нормально, но потом тестировщик найдёт ошибку. А если это сделает автоматика, это намного быстрее и экономия труда, половины рабочего дня тестировщика.


Вы сказали программиста носом натыкать. Это тот самый конфликт между разработкой и QA, о котором говорил Тимофей?


А: Могу привести свой пример, поскольку работаю с CI/CD каждый день, но не с кодом, а с конфигурациями. У нас есть линтеры лишний пробел поставил, он уже ругается. Иногда злишься, ведь это просто формальность, ни на что не повлияет, но это приучает к качеству. И стандарты эти нужны для обеспечения командной работы в том числе. Чтобы новый человек пришел и быстро разобрался.


Получается, весь процесс настройки CI/CD как бы против программиста. Разработчик раньше был этаким свободным художником, а теперь приходит DevOps-инженер и говорит ему, как работать.


А: Можно провести аналогию с конвейером. Если норма у рабочего на конвейере пять деталек в час, а он такой стахановец и делает десять. Это уже может быть непредсказуемость, если мы всегда будем считать, что он делает десять, хотя норма пять. Поэтому лучше пусть стабильно делает пять, но качественно. Можно фигачить код без стандартов, он будет работать, но новый человек не въедет быстро. Поэтому в командной работе есть ограничения, чтобы ото всех можно было получить одинаково стабильную работу. А не так, что один вкалывает, а другой сидит.


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


Давайте мы теперь чуть отступим и поговорим про внедрение CI/CD. Как компании и команды приходят к тому, что пора что-то менять? Ошибки слишком частые, порядка нет, что-то ещё?


Т: Это очень по-разному случается. Вот мой опыт в X5 был такой, что была полная поддержка со стороны менеджмента, но при этом есть менеджмент всей дирекции, а есть отдельные продуктовые команды, у которых некое двоевластие. С одной стороны, есть руководитель отдела разработки, который, наверное, ратует за поставку качественного кода, но, с другой стороны, это продуктовая команда, у них есть дедлайны для поставки фич, и не всегда ясно, что поставить в приоритет. Конечно, нет откровенно глупых людей, которые говорят, что весь этот ваш DevOps не важен, нам нужно фичи пилить. Но при этом в разговорах проскакивает моментами. Мол, ну, я не знаю, у меня сейчас есть бюджет на одну ставку, и для меня вывод очевиден, кого я возьму DevOps или ещё одного разработчика. Мне нужно разрабатывать, так что я возьму разработчика.


Как сделать хорошую мину при плохой игре? Поскольку у нас есть такой инфраструктурный отдел, который ещё в какой-то степени DevOps-евангелисты, то есть отдел, которым я руководил в X5, лучшее, что можно сделать, это облегчить командам внедрение этих пайплайнов, этого CI/CD. Обучать людей до тех пор, пока это возможно, но лучше всего что-то сделать за них. Зашаблонизировать типовые действия. Например, даже банально собрать докер-образ и запушить его в репозиторий. Это нужно авторизоваться в docker registry. Рассчитать, с каким тегом мы соберем докер-образ. Это docker build, потом пуш несколько раз. Возможно, если мы хотим кэши, то нужно сначала скачать старый образ, который уже был, использовать его как кэш, потом закачать новый. Это куча рутины, которая может растянуться строчек на пятнадцать, но это всё однотипно.


Если инфраструктурная команда понимает немного в DevOps, она осознаёт, что это её задача. Сделайте Developer Experience получше. Зашаблонизируйте это, чтобы умещалось в три строчки, а не в пятнадцать. Тогда разработчики будут мыслить не категориями: надо спулить образ, собрать, туда-сюда. А категориями: а вот здесь Docker. Просто один блок, модульный такой. И им будет легче. Они тогда смогут абстрагироваться от деталей и больше заниматься своей непосредственной работой. А именно писать код. В этом плане DevOps он в том, чтобы фасилитировать, предоставлять разработчикам возможность лучше делать свою работу.
И таким образом снижать сопротивление.

А: Отвечу на тот же вопрос со своей стороны. У меня пример внедрения не из мира разработки, больше из мира администрирования. У нас в один прекрасный момент сказали: Мы вот подошли к тому, что откладывать нельзя. Базис мы подготовили для вас. Теперь все новые проекты вы будете создавать вместо старого пути по CI/CD. Вот у вас есть шаблончик, создаете в GitLab и работаете с ним. Каждая команда будет вольна его улучшать. Так и внедряли. Достаточно императивно. В некоторых проектах, когда этот путь нёс больше вреда, чем пользы, мы откатывались на старую версию, но сейчас половина проектов работают через CI/CD. Мы управляем конфигурациями серверов через GitLab CI. Точно так же, как у разработчиков, там есть проверки, линтеры.


Раз уж заговорили про администрирование, поговорим про GitOps. Что это такое, и какое значение имеет: это всё-таки хайп или полезность?


А: Мало что могу сказать про GitOps. Мое мнение такое, что это достаточно хайповое слово. В последнее время я много его слышу. Три года назад так хайповали на DevOps, так что GitOps для меня одно из слов, примазавшихся к DevOps. Для меня это больше хайп.


Это вообще о том, что вся правда хранится в Git. Там и управление конфигурациями серверов, Infrastructure-as-Code, и код проекта, который потом на эти сервера поедет, и описание процесса, как мы с исходного кода получаем приложение на серверах. Так это я понимаю. Возможно, Тимофей меня дополнит, исправит.


Т: GitOps, мне кажется, чуть более честное словечко, чем все эти DevOps, DevSecOps и так далее. Потому что оно значит почти буквально то, что и говорит. Это именно ведение своих действий по эксплуатации своего софта, своей инфраструктуры через Git. Вся правда хранится в Git.


Что это на практике значит? Вроде как мы запушили какой-то код в наш репозиторий, автоматически запустился пайплайн. Что-то произошло, допустим, какие-то манифесты отправились в Kubernetes. И вот у нас то, что мы запушили в Git, это теперь то, что находится в Kubernetes. В принципе, это тоже GitOps, хотя не всегда его так называют. В частности, это так называемая push-модель, когда мы информацию из репозитория толкаем на продакшн.


Еще бывает так называемая pull-модель. Когда, если речь идет о Kubernetes, то у нас там какой-то агент стоит, который мониторит изменения в репозиториях, и если видит, что там что-то закомитили, что-то изменилось, то он стягивает эти изменения. Он умеет и Helm, и Kustomize делать, и просто манифесты ямликами подтягивать. И опять же отправляет их в Kubernetes.


Некоторые пропоненты GitOps вовсе закрывают любое редактирование в Kubernetes и позволяют изменять состояние кластера, только подтягивая изменения из Git. Если этого не делать, всегда есть риск, что из-за чьих-то ручных действий состояние кластера и то, что описано в репозитории разъедется. Кто-то там ручками что-то поменял, а в Git ничего не поменялось. Поэтому частенько говорят про GitOps именно в контексте pull-модели, когда, ну, поменял ты что-то в Kubernetes, ничего страшного, потому что автоматика в ближайшие полчаса все равно вернет все, как описано в Git.


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


К примеру, смежный отдел, который управлял Data Lake в X5, быстро пришёл к тому, что у них вся конфигурация из двух сотен машин управлялась через Ansible, а он запускался каждые 30 минут, как пайплайн в GitLab. Это пример более-менее правильного применения GitOps.


Ну, и те инструменты, которые для GitOps используются, они ещё в какой-то мере нам подсвечивают: а у нас задеплоено именно то, что мы хотим? Иногда они не возвращают автоматически состояния, а просто зажигается желтый или красный светофор: Оп, ребята, у вас рассинхронизировалось состояние тут и тут.


Александр, когда вы говорили о том, как строите процесс работы с клиентами в Southbridge, вы упоминали что-то похожее на GitOps. Настройка конфигурации через описание в Git, это не то же самое?


А: В идеальном мире да. Но у софта зачастую очень много настроек. И чтобы в каждой ручечку/переключатель/ползунок поменять, роль управления конфигурацией должна быть очень развесистая, раскидистая. Либо шаблонизированная. Иногда бывает, что настройки просто нет, и мы идем вручную поправляем. Разработка не успевает за эксплуатацией. Потому что иногда задачи бывают критичные. А чтобы всё разработать, у нас просто нет времени. Но в идеальном случае мы делаем именно то, что описал Тимофей.


Тимофей, а подход GitOps учитывает это обстоятельство неидеального мира?


Т: Это тяжело, конечно. Потому что нам надо бизнес делать, бабки зарабатывать. Казалось бы, вот она, ручка, сходи и поменяй, надо же. Есть потребность, а тут какой-то скрипт ещё писать, дорабатывать helm-чарты. Поэтому да, есть соблазн всё быстренько сделать руками.
Чтобы и бизнес-потребности учесть и себе codebase не испортить, можно хотя бы завести тикет, что вот тут вручную настраиваемое значение, но это баг. Мы положим тикет в бэклог, потом обязательно вернемся и допилим тут автоматизацию. Главное не потерять места, где мы руками настраивали.


В чём ключевые преимущества подхода GitOps?


Т: Основное мы достоверно знаем, что у нас запущено в продакшене. Что все четко описано в репозитории, и не возникает сомнений, что кто-то руками поменял.


А: Когда большая команда, это очень важно, что все могут в любой момент посмотреть и увидеть, какая сейчас конфигурация работает на нужном сервере. Потому что если там 1-2 человека, они могут всегда договориться, а когда 15 человек, GitOps сильно экономит время. Не надо ходить, опрашивать, выяснять, откуда ноги растут у несоответствий.


Чем GitOps отличается от подхода Infrastructure-as-Code?


А: Это не только инфраструктура, но еще и приложение, как код. Они хранятся в единой точке. Может, в разных репозиториях, но в одном инстансе GitLab. Можно легко посмотреть состояние инфраструктуры и приложения. Плюс, в идеальном мире может быть вообще связана инфраструктура с кодом. Мы создали новый репозиторий, настроили с нуля хитрый пайплайн, запушили код и он сам пошёл, создал себе инфраструктуру где-нибудь в облаке и задеплоил туда приложение, которое мы туда написали. Это идеальный, конечно, случай, но думаю, где-то это работает. Например, в больших компаниях.


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


Это такая идеальная система?


Т: Ну, да.


CI/CD это такая штука, которую один раз настроил и забыл, или это процесс, который нужно поддерживать?


Т: И да, и нет. Когда он только внедряется, не бывает сразу идеально. Когда в X5 я внедрял, то начальник отдела разработки спрашивал у разработчиков, сколько времени в неделю они тратят на обслуживание их CI/CD. Кто-то отвечал: А что там обслуживать? Вот мы настроили и забыли. И какое-то время это работает. Если сделать сходу правильно, можно сделать очень модульные блоки. И потом не сильно трогать нижележащий код, который это делает, а просто появился новый проектик/микросервис, подключили к нему типовые модульные блоки и поехали дальше. Но пока все учатся, что-то допиливается. Приходится на первых порах долго и мучительно внедрять новые хорошие практики в трудно обслуживаемый код. Дальше уже полегче.


А в больших компаниях как обычно происходит? Приходит DevOps, помогает всё это настроить и остается в команде, или разработчики перенимают на себя его функции, а DevOps уходит в другую команду? Или есть отдел DevOps?


Т: Все очень по-разному. У меня в X5 были продуктовые команды очень разных способностей. Какие-то хорошо въезжали в процесс, и редко надо было им помогать. Были более слабые. К ним привязывали инженера, который помогал писать пайплайны. Работал, в некоторой степени, приходящим релиз-инженером в их команде. Но в X5 порядка 9-10 DevOps обслуживали потребности где-то 200 техспециалистов.


Сейчас я работаю в Тинькофф, тоже в платформенной команде, но там масштабы немного другие. Нас 8 человек, а разработчиков тысячи полторы. И невозможно предоставлять каждой команде DevOps как сервис. Поэтому там предполагается, что команда сама добывает эту экспертизу или нанимает себе DevOps. Либо сами разработчики этому обучаются.


А: Моя версия такая, что да, вначале идет активная разработка. Мы программируем пайплайн, что за чем будет идти, потом ситуация может устаканиться. Если в архитектуре проекта нет глобальных изменений, всё может работать год без правок. Но в мире все меняется. Микросервисы могут быть переписаны за две недели. И если их переписали на другом языке программирования, то тесты выкидываем и пишем новые. Поэтому CI/CD тоже требует обслуживания.


Ну и добавлю, что у разработчиков разная компетенция. Кому-то постоянно нужна помощь, а кому-то нет. Вот у нас был пример с одним из клиентов. Мы им настроили базовые CI/CD, всё показали. Через какое-то время они к нам приходят и говорят: А мы вот переписали всё по-своему. Мы только и ответили: Ух ты, молодцы. Они просто взяли все в свои руки.

Подробнее..

Учимся читать логи ваших бекапов

26.11.2020 10:08:34 | Автор: admin

Скажите честно, в своей практике вам чаще приходилось сталкиваться с логами, напоминающими чей-то поток сознания, или всё же это были красивые структурированные файлы, на которые любо-дорого смотреть? Надеюсь, что второе. В наших продуктах, само собой, мы тоже стремимся идти по второму пути, однако необходимость зафиксировать большое количество процессов накладывает свой отпечаток. Так что сегодня мы научимся не читать книгу и видеть фигу, а бесстрашно открывать любой лог Veeam Backup & Replication и видеть его внутреннюю красоту.

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

Когда читаешь логи, очень важно держать в голове и применять шесть простых правил.

Правило первое: В логах тьма ошибок с ворнингами и это нормально. Не надо бросаться на первую попавшуюся ошибку и пытаться с ней что-то сделать. Как мы помним из прочитанных ранее статей, в логах фиксируется вся информация, которая приходит от разнородных систем, включая внешние. Ошибка может обозначать переход между режимами или быть банальной проверкой. Вот пример:

// Виму надо отключиться от vCenter:[19.10.2020 05:02:53] <01> Info [Soap] Logout from "https://vcenter.test.local:443/sdk"// Убеждаемся, что мы действительно отключились, попробовав выполнить любое действие. Получить ошибку здесь  ожидаемый результат.[19.10.2020 05:02:53] <01> ErrorThe session is not authenticated. (System.Web.Services.Protocols.SoapException)[19.10.2020 05:02:53] <01> Error at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)

Правило второе: Когда читаете лог, не надо смотреть только на последнюю в списке ошибку. Даже если она подсвечена в репорте, упавшем на почту. Причина её появления запросто может быть на пару экранов (и десяток других ошибок) выше. Например, в упавшем на почту HTML репорте видим ошибку "Microsoft SQL server hosting the configuration database is currently unavailable". Открываем лог джобы и видим, что последняя ошибка в логе прямо нам говорит Не могу подключиться к SQL серверу, потому что <причины>.

[12.11.2019 23:24:00] <18> Error Microsoft SQL server hosting the configuration database is currently unavailable. Possible reasons are heavy load, networking issue, server reboot, or hot backup.[12.11.2019 23:24:00] <18> Error Please wait, and try again later.

Сразу хочется победно прокричать Ага! и побежать чинить связь до SQL сервера, перезагружать его, трясти за бампер и пинать по колесу. Однако если попробовать разобраться и отмотать лог ближе к началу, там обнаруживаются строки:

12.11.2019 23:22:00] <18> Error Violation of PRIMARY KEY constraint 'PK_Storages'. Cannot insert duplicate key in object 'dbo.Backup.Model.Storages'. The duplicate key value is (af4d30aa-9605-4fe6-8229-f362eb848f19).[12.11.2019 23:22:00] <18> Error Violation of PRIMARY KEY constraint 'PK_Storages'. Cannot insert duplicate key in object 'dbo.Backup.Model.Storages'. The duplicate key value is (af4d30aa-9605-4fe6-8229-f362eb848f19).

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

Правило третье: Редкая ошибка локализуется внутри одного конкретного лога. Изучение соседних логов на тот же момент времени позволяет собрать намного больше информации. Хрестоматийный пример это лог джобы, где нам просто говорят, что возникала такая-то ошибка в такой-то таске. Какие-то выводы, конечно, мы сделать уже можем, но лучше открыть лог таски и получить более подробное описание случившегося бедствия. И если уж совсем ничего не понятно, то нам на помощь приходят логи агентов, в которых вся ситуация будет разобрана крайне подробно. Но тут действует правило Чем дальше в лес, тем более узким и специфичным становится лог. А ещё часть инфы может всплыть в сервисных логах, часть в виндовых ивентах и так далее.

Вот, например, берём типичный лог упавшей джобы:

[13.06.2019 11:06:07] <52> Error  Failed to call RPC function 'CreateSessionTicket': Agent with the specified identifier '{c8fdc9b9-0d60-486c-80de-9fc4218d276f}' does not exist

Типичный никчёмный Failed to call RPC function, из которого максимум, что можно понять что не удалось провзаимодействовать с транспортным агентом. Однако если вспомнить, что транспортный агент управляется транспортным сервисом (известен в документации как Datamover) и заглянуть в его лог (Svc.VeeamTransport.log) на хосте, где он запускался, то можно обнаружить:

[13.06.2019 09:05:07] < 10648> tpl|   Agent '{c8fdc9b9-0d60-486c-80de-9fc4218d276f}' will be terminated due to reason: some I/O operation has hanged.[13.06.2019 09:06:07] < 10648> tpl| WARN|AGENT [{c8fdc9b9-0d60-486c-80de-9fc4218d276f}] HAS HANGED UNEXPECTEDLY AND WAS TERMINATED.

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

Правило четвёртое: Если в логах видим, что ошибка происходит где-то за границами компонентов VBR, значит, искать их причину надо тоже за границами компонентов VBR. Veeam хоть и старательно логирует все приходящие к нему события, однако ещё больше их(событий) остаётся на целевой системе. Типичным примером здесь будет создание VSS снапшота. По большому счёту, Windows отдаёт информацию на уровне получилось или нет что-то сделать, из чего крайне редко получается вычленить причину, почему же не получилось. Однако внутри виндовых ивентов можно найти множество событий, прямо указывающих на проблему. Главное всегда тщательно сопоставлять время в логах от разных систем. Помним, что у VBR своё время, у vSphere всегда UTC+0, а виндовые ивенты показываются в локальном времени машины, на которой их смотрят. Типичные примеры экспорта внешних логов для Windows и для Microsoft SQL.

Правило пятое: Следи за тредами (они обозначаются как <XX>) и распутывай клубок последовательно! Многие вещи могут происходить параллельно, и если просто читать логи линия за линией, то можно прийти к неправильному выводу. Особенно это важно, если джоба кажется зависшей и надо понять, что именно в ней зависло.

Вот типичный лог для этой ситуации:

[18.06.2020 03:44:03] <36> Info [AP] Waiting for completion. Id: [0xf48cca], Time: 00:30:00.0333386[18.06.2020 03:45:18] <53> Info [AP] (6ff9) output: --asyncNtf:Pipeline timeout: it seems that pipeline hanged.

Если читать это лог, не обращая внимания на номера тредов <36> и <53>, то кажется, что у нас какие-то проблемы с агентом 6ff9, и надо срочно разбираться, что с ним случилось. Однако если продолжить чтение лога с оглядкой на тред <36>, то обнаруживается, что:

[18.06.2020 03:14:03] <36> Info  [AP] (bf19) command: 'Invoke: DataTransfer.SyncDisk

То есть этот тред посвящён совершенно другому агенту с id bf19! Открываем лог этого агента и видим:

[17.06.2020 12:41:23] <  2160>  ERR |Data error (cyclic redundancy check).[17.06.2020 12:41:23] <  2160>  >>  |Failed to read data from the file [E:\Hyper-V\VHDs\SRV-DCFS02\SRV-DCFS02-C.vhdx].

Значит, проблема в битом VHDX и надо искать методы его лечения.

Правило шестое: Не получается, непонятно, кажется, что вот-вот, но идёт третий день без сна и всё никак звони в сапорт! Veeam огромный продукт, где есть тысячи нюансов, нюансы для нюансов и прочих сокровенных знаний, которые никогда не понадобятся 99,99% населения этой планеты. Однако именно этих знаний в большинстве случаев и не хватает, чтобы успешно найти причину неисправности самому. Сапорт Вима совсем не просто так получает свою зарплату и считается одним из лучших в IT-индустрии. А ещё он русскоязычный и доступен по телефону ;)

Смело открываем лог

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

===================================================================Starting new logLog has been started by 'VEEAM\SYSTEM' user (Non-interactive)Logging level: [4 (AboveNormal)]MachineName: [VEEAM], OS: [Microsoft Windows Server 2019 Standard (10.0.17763)], CPU: [2]Process: [64 bit], PID: [10816], SessionId: [0]UTC Time: [22.10.2020 2:03:53], DaylightSavingTime: [False]Culture: [ru-RU], UI culture: [en-US]Module: [C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Manager.exe]. File version: [10.0.1.4854], Assembly version: [10.0.0.0], Edition: [standard]Process start time: [22.10.2020 0:01:19], Garbage collector mode: [Workstation]CmdLineParams: [startbackupjob owner=[vbsvc] Normal bed49ecd-54a4-4f53-b337-e71fabe92988 44c3f481-66ec-475f-bd04-a321e69274a0]Network Interface, Name: Ethernet0, Description: Intel(R) 82574L Gigabit Network Connection, Interface Type: Ethernet, Operational Status: Up;Unicast IPAddresses: fe80::b99c:9c8a:6179:295b%6; 172.17.32.51;Gateway IPAddresses: 172.17.32.1;Network Interface, Name: Loopback Pseudo-Interface 1, Description: Software Loopback Interface 1, Interface Type: Loopback, Operational Status: Up;Unicast IPAddresses: ::1; 127.0.0.1;UTC offset: 3,00 hours

Начало не вызывает никаких особых вопросов. Мы видим, как называется машина, на которой установлен VBR, и под каким пользователем запускается Veeam Backup Service.

Log has been started by 'VEEAM\SYSTEM' user (Non-interactive)MachineName: [VEEAM], OS: [Microsoft Windows Server 2019 Standard (10.0.17763)],

Важный пункт это версия запускающегося модуля.

Module: [C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Manager.exe]. File version: [10.0.1.4854], Assembly version: [10.0.0.0], Edition: [standard]

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

Затем идёт перечисление всех сетевых интерфейсов и их IP-адреса. Также по названию карты зачастую можно понять, стоит ли Veeam на виртуальной машине или на физической. Хотя вы и сами наверняка это знаете, но может пригодиться.

Network Interface, Name: Ethernet0, Description: Intel(R) 82574L Gigabit Network Connection, Interface Type: Ethernet, Operational Status: Up;Unicast IPAddresses: fe80::b99c:9c8a:6179:295b%6; 172.17.32.51;Gateway IPAddresses: 172.17.32.1;Network Interface, Name: Loopback Pseudo-Interface 1, Description: Software Loopback Interface 1, Interface Type: Loopback, Operational Status: Up;Unicast IPAddresses: ::1; 127.0.0.1;

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

UTC Time: [22.10.2020 2:03:53], DaylightSavingTime: [False]UTC offset: 3,00 hours

Теперь, когда заголовок прочитан, давайте на примере бекапа и реплики посмотрим, что нас ожидает в логе любой джобы. Я не буду объяснять каждую строчку, иначе мы отсюда через месяц только разойдёмся. Просто легкая пробежка по общему принципу.

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

  • Затем формируется список объектов, участвующих в бекапе.

  • Для всех объектов надо заблокировать необходимые ресурсы (файлы с бекапами, например) и убедиться, что никто другой не пытается с ними работать в этот момент времени.

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

  • После чего можно запускать отдельные таски и ждать отчёта об их успешном (хочется верить, что да) выполнении.

  • И в конце, когда все таски отчитались, наступает тяжелая пора проверки ретеншенов. Удаляются старые точки, запускаются синтетические трансформы и прочий страшный сон для ваших СХД.

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

Теперь давайте обратим внимание на таски. Каждая таска запускается с чётко поставленной целью забекапить конкретную машину. Значит, после запуска её дело это суметь подключиться к хосту, запустить агентов (в документации известны как data movers), проверить, что есть связь между компонентами, и совершить процесс передачи информации от хранилища вашего хоста до бекапного репозитория с необходимыми трансформациями по пути. Сжатие, разжатие, дедупликация, шифрование и так далее.

Соответственно, начинаем поиски проблемы широкими мазками, а именно выясняем, на каком моменте всё сломалось. В этом нам помогает волшебное словосочетание has been completed. В общем случае таски рапортуют таким образом:

[19.10.2020 05:02:44] <29> Info Task session [3af0e723-b2a3-4054-b4e3-eea364041402] has been completed, status: Success, 107,374,182,400 of 107,374,182,400 bytes, 55,326,015,488 of 55,326,015,488 used bytes, 14 of 14 objects, details:

14 объектов это так называемые OiB, Object in Backup. Эта информация дублируется в логе джобы после завершения каждой таски с пометкой о том, сколько тасок уже завершилось. А в самом конце джоба должна заканчиваться полным отчётом.

[19.10.2020 05:02:53] <01> Info Job session '0f8ad58b-4183-4500-9e49-cc94f0674d87' has been completed, status: 'Success', '100 GB' of '100 GB' bytes, '1' of '1' tasks, '1' successful, '0' failed, details: '', PointId: [d3e21f72-9a52-4dc9-bcbe-98d38498a3e8]

Другая полезная фраза это Preparing point. Позволяет нам понять, какой тип бекапа сейчас будет создаваться.

В случае создания полного бекапа, в народе именуемого фульник (Full или Active full), создаётся следующая запись:

[17.11.2019 22:01:28] <01> Info Preparing point in full mode 

Инкрементальный проход выглядит вот так:

[17.11.2019 22:01:28] <01> Info Preparing point in incremental mode 

И реверс инкремент:

[17.11.2019 22:01:28] <01> Info Preparing point in synthetic mode 

Для Synthetic full своей особой записи не существует! Она начинает с создания обычного инкремента, поэтому надо искать ниже в логе запись "Creating synthetic full backup". Или пройтись по "Preparing oib" в логе таски.

vSphere

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

И начнём мы именно с VMware. Для начала просто посмотрим версию хоста по слову Build- в логе джобы. Так мы сможем узнать версию и номер билда хоста с машиной. Если хост был добавлен как часть Vcenter, бонусом получаем поле source host type.

[01.11.2020 05:00:26] <01> Info VM task VM name: 'vudc01', VM host name: 'https://esxi.test.local', VM host info: 'VMware ESXi 6.5.0 build-16207673', VM host apiVersion: '6.5', source host name: 'vcenter.test.local', source host id: '3de6c11c-ad7e-4ec0-ba12-d99a0b30b493', source host type: 'VC', size: '107374182400', display name: 'vudc01'.

Эта же информация дублируется в момент проверки доступных режимов работы прокси.

[01.11.2020 05:00:24] <01> Info [ProxyDetector] Proxy [dsg.test.local] lies in different subnet with host [VMware ESXi 6.5.0 build-16207673]

В логе соответствующей таски это всё тоже имеется, только там это часть здоровенной XML, так что копипастить я её не буду. Зато там есть даже более интересная строка Host content info:

[01.11.2020 05:01:37] <37> Info  [Soap] Host content info: host "vcenter.test.local", type "vpx", version "6.5.0", build "15259038", apiVersion "6.5", hostTime "01.11.2020 2:01:26", sessionKey: "52c2dbf9-1835-2eb3-bb0e-396166a8101f"

Там же, в логе таски, можно получить информацию о дисках и датасторах по строке Disk: label

[07.08.2019 06:55:41] <82> Info Disk: label "Hard disk 1", path "[ALLIN_PURE_GDI] LXRP-IT-GPILDB1/LXRP-IT-GPILDB1_21.vmdk", capacity 25,0 GB, backing "CFlatVirtualDiskV2", mode "persistent", thinProvisioned "False"

Как мы видим, нас интересует ALLIN_PURE_GDI, поэтому переключаемся на лог джобы и видим:

[12.08.2019 05:40:12] <01> Info [ProxyDetector] Datastore 'ALLIN_PURE_GDI' lun was found, it uses vmfs

или

[12.08.2019 05:40:12] <01> Info [ProxyDetector] Datastore 'ALLIN_PURE_GDI' lun was found, it uses nas

Ещё бывает "Backup VM 'VMname' is DirectNFS compatible", но это не значит, что наша машина точно на NFS шаре.

Жизненный цикл vSpehere снапшотов

и места, где они обитают.

Часто (а на самом деле практически всегда) понимать, в какой момент создавался снапшот, в какой был удалён и что с ним происходило, весьма важно для получения целостной картины мира реплик и бекапов. Поэтому открываем лог таски и ищем в нём API вызовы для создания и консолидации (удаления) снапшотов. Создание снапшота отлично ищется по Create snapshot

[02.11.2020 05:01:09] <29> Info [VimApi] Create snapshot, ref "vm-26", name "VEEAM BACKUP TEMPORARY SNAPSHOT", description "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "False"[02.11.2020 05:01:11] <29> Info [Soap] Snapshot VM 'vm-26' was created. Ref: 'snapshot-540'

Удаление снапшота ищется по Removing snapshot.

[01.11.2020 05:02:30] <26> Info [Soap] Removing snapshot 'snapshot-536'[01.11.2020 05:02:30] <26> Info [VimApi] RemoveSnapshot, type "VirtualMachineSnapshot", ref "snapshot-536", removeChildren "False"[01.11.2020 05:02:32] <26> Info [VmSnapshotTracker] Snapshot id: 'snapshot-536' closed[01.11.2020 05:02:32] <26> Info [Soap] Loaded 2 elements[01.11.2020 05:02:32] <26> Info [ViSnapshot] Checking if disks consolidation is needed for vm 'vm-26'[01.11.2020 05:02:32] <26> Info [ViSnapshot] Consolidation is not needed

Здесь что хочется отметить: по загадочной причине в логе VMware.log зачастую нет никакой информации об ошибках произошедших во время создания/удаления снапшота. Поэтому полную картину мира надо восстанавливать по всем логам vSphere, включая логи VPXD и HOSTD.

С точки зрения vSphere, в VMware.log обычно есть только события на создание снапшота:

2019-05-24T13:58:57.921Z| vmx| I125: SnapshotVMX_TakeSnapshot start: 'VEEAM BACKUP TEMPORARY SNAPSHOT', deviceState=0, lazy=0, quiesced=0, forceNative=0, tryNative=1, saveAllocMaps=0 cb=35DE089A0, cbData=35F700420 ....2019-05-24T13:59:01.111Z| vcpu-0| I125: VigorTransport_ServerSendResponse opID=a9e2725d-8d3e-41c3-bea7-40d55d4d13fe-3088830-h5c:70160745-a8-af-3321 seq=187319: Completed Snapshot request. 

И на удаление:

2019-05-24T13:59:31.878Z| vmx| I125: SNAPSHOT: SnapshotDeleteWork '/vmfs/volumes/5b0c32e4-3bc067bb-614b-f4e9d4a8b220/test_build/test_build.vmx' : 29....2019-05-24T13:59:35.411Z| vcpu-0| I125: ConsolidateEnd: Snapshot consolidate complete: The operation completed successfully (0).

Причём снапшоты, сделанные вручную, логируются несколько иначе, но это детали.

Зато как только мы заводим разговор о репликах, всё становится ещё веселее. VMware.log ведётся только когда виртуалка работает. А для реплицированных машин нормальное состояние быть выключенными. Так что этот лог вам никак помочь не может. Поэтому здесь нам понадобятся логи vCenter или хоста. Самый простой способ их добыть это ПКМ на vCenter > Export System Logs. В открывшемся визарде обязательно выбираем "Include vCenter server logs" и дожидаемся скачивания результата. Логи влёгкую могут весить несколько гигабайт, а скачиваться будут через браузер. Так что советую делать это на машине максимально близкой к VC. Самое интересное для нас внутри, это:

  • ESXi: В архиве проходим по /var/run/log/ и находим hotsd.log. Рядом будут лежать упакованные более ранние версии.

  • VC: ищем файлы vpxd-xxx.log по пути /var/log/vmware/vpxd.

Теперь давайте сравним, как будут выглядеть записи об одних и тех же операция в логе VBR, логе vpxd, и логе hostd. Здесь мы опустим моменты создания снапшота на исходной машине, так как нас интересует только реплика.

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

//Veeam Task log:[19.05.2020 18:41:04] <20> Info [SnapReplicaVm] Find working snapshots for replica vm '[name 'TinyLinux2_replica', ref 'vm-3411']'[19.05.2020 18:41:04] <20> Info [SnapReplicaVm] Reverting vm '[name 'TinyLinux2_replica', ref 'vm-3411']' to restore point '5/19/2020 15:37:13'[19.05.2020 18:41:04] <20> Info [Soap] Reverting snapshot snapshot-3415[19.05.2020 18:41:04] <20> Info [VimApi] RevertSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3415"
//VPXD:2020-05-19T15:41:00.508Z info vpxd[04767] [Originator@6876 sub=vpxLro opID=7717265a] [VpxLRO] -- BEGIN task-32169 -- snapshot-3415 -- vim.vm.Snapshot.revert -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)
//Hostd:2020-05-19T15:41:00.492Z info hostd[2099911] [Originator@6876 sub=Vimsvc.TaskManager opID=7717265a-a1-62d8 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.vm.Snapshot.revert-53704072020-05-19T15:41:00.652Z info hostd[2099895] [Originator@6876 sub=Vimsvc.TaskManager opID=7717265a-a1-62d8 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Completed : haTask-676-vim.vm.Snapshot.revert-5370407 Status success

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

//Veeam Task log:[19.05.2020 18:41:17] <20> Info [SnapReplicaVmTarget] Creating working snapshot[19.05.2020 18:41:17] <20> Info [SnapReplicaVm] Creating working snapshot for replica vm '[name 'TinyLinux2_replica', ref 'vm-3411']'[19.05.2020 18:41:19] <20> Info [VimApi] Create snapshot, ref "vm-3411", name "Veeam Replica Working Snapshot", description "<RPData PointTime="5249033617402408751" WorkingSnapshotTime="5249033617402408751" PointSize="0" PointType="EWorkingSnapshot" DescriptorType="Default" />", memory "False", quiesce "False"[19.05.2020 18:41:21] <20> Info [Soap] Snapshot VM 'vm-3411' was created. Ref: 'snapshot-3416'
//VPXD:2020-05-19T15:41:15.469Z info vpxd[00941] [Originator@6876 sub=vpxLro opID=32de210d] [VpxLRO] -- BEGIN task-32174 -- vm-3411 -- vim.VirtualMachine.createSnapshot -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)
//Hostd:2020-05-19T15:41:15.453Z info hostd[2099906] [Originator@6876 sub=Vimsvc.TaskManager opID=32de210d-b7-635b user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.VirtualMachine.createSnapshot-53704362020-05-19T15:41:15.664Z info hostd[2099914] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.VirtualMachine.createSnapshot-5370436 Status success

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

//Veeam Task log:[19.05.2020 18:41:44] <20> Info [Soap] Reverting snapshot snapshot-3416[19.05.2020 18:41:44] <20> Info [VimApi] RevertSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3416"[19.05.2020 18:41:46] <20> Info [Soap] Removing snapshot 'snapshot-3416'[19.05.2020 18:41:46] <20> Info [VimApi] RemoveSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3416", removeChildren "False
//VPXD:2020-05-19T15:41:40.571Z info vpxd[22153] [Originator@6876 sub=vpxLro opID=15fb90d9] [VpxLRO] -- BEGIN task-32176 -- snapshot-3416 -- vim.vm.Snapshot.revert -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)2020-05-19T15:41:42.758Z info vpxd[17341] [Originator@6876 sub=vpxLro opID=1b7624e9] [VpxLRO] -- BEGIN task-32177 -- snapshot-3416 -- vim.vm.Snapshot.remove -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)
//Hostd:2020-05-19T15:41:40.966Z info hostd[2099914] [Originator@6876 sub=Vimsvc.TaskManager opID=15fb90d9-ad-6417 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Completed : haTask-676-vim.vm.Snapshot.revert-5370516 Status success2020-05-19T15:41:42.764Z info hostd[6710321] [Originator@6876 sub=Vimsvc.TaskManager opID=1b7624e9-89-6435 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.vm.Snapshot.remove-53705222020-05-19T15:41:42.995Z info hostd[2099912] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.vm.Snapshot.remove-5370522 Status success

Но поскольку свято место пусто не бывает, сразу после удаления этого снапшота надо создать новый, который возьмёт на себя ответственность называться Restore Point. Хотя фактически он служит той же цели запрещает изменять предыдущую дельту, где лежат данные с боевой машины.

//Veeam Task log:[19.05.2020 18:41:51] <20> Info [VimApi] Create snapshot, ref "vm-3411", name "Restore Point 5-19-2020 18:40:53", description "<RPData PointTime="5248941014961933064" WorkingSnapshotTime="5249033617402408751" PointSize="64" PointType="ECompleteRestorePoint" DescriptorType="Default" />", memory "False", quiesce "False"[19.05.2020 18:41:53] <20> Info [Soap] Snapshot VM 'vm-3411' was created. Ref: 'snapshot-3417'
//VPXD:2020-05-19T15:41:47.170Z info vpxd[48063] [Originator@6876 sub=vpxLro opID=5cc1af26] [VpxLRO] -- BEGIN task-32179 -- vm-3411 -- vim.VirtualMachine.createSnapshot -- 52e02fc8-9bbb-74da-63ac-74879274c5a3(52e50ab9-39d5-0996-21ce-3877ead7a6e9)
//Hostd:2020-05-19T15:41:47.155Z info hostd[2099311] [Originator@6876 sub=Vimsvc.TaskManager opID=5cc1af26-f3-646c user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.VirtualMachine.createSnapshot-53705392020-05-19T15:41:47.303Z info hostd[2099419] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.VirtualMachine.createSnapshot-5370539 Status success

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

//Veeam Job Log:[19.05.2020 18:42:21] <49> Info [SnapReplicaVm] DeleteRestorePoint 'PointTime: 5/19/2020 15:33:10, DigestStorageTimeStamp: 9/3/2020 19:51:05, SnapshotRef: snapshot-3413, Type: Default'[19.05.2020 18:42:21] <49> Info [Soap] Removing snapshot 'snapshot-3413'[19.05.2020 18:42:21] <49> Info [VimApi] RemoveSnapshot, type "VirtualMachineSnapshot", ref "snapshot-3413", removeChildren "False"
//VPXD:2020-05-19T15:42:17.312Z info vpxd[49540] [Originator@6876 sub=vpxLro opID=7e40daff] [VpxLRO] -- BEGIN task-32181 -- snapshot-3413 -- vim.vm.Snapshot.remove -- 528b44cf-9794-1f2d-e3ff-e3e78efc8f76(52b14d11-1813-4647-353f-cfdcfbc6c149)
//Hostd:2020-05-19T15:42:17.535Z info hostd[2099313] [Originator@6876 sub=Vimsvc.TaskManager] Task Completed : haTask-676-vim.vm.Snapshot.remove-5370588 Status success2020-05-19T15:42:17.302Z info hostd[6710322] [Originator@6876 sub=Vimsvc.TaskManager opID=7e40daff-e0-6513 user=vpxuser:VSPHERE.LOCAL\Administrator] Task Created : haTask-676-vim.vm.Snapshot.remove-5370588

Ищем компоненты

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

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

И да, это будет опять vSphere. Получить общую информацию проще всего в логе таски по строке Processing object

[02.11.2020 05:00:38] <29> Info Processing object 'vudc01' ('vm-26') from host 'vcenter.test.local' ('3de6c11c-ad7e-4ec0-ba12-d99a0b30b493')

Чуть ниже уже будет более подробная информация в строке VM information. Как видим, для машин, добавленных через VC, указывается, в том числе, и хост.

[01.11.2020 05:00:46] <26> Info VM information: name "vudc01", ref "vm-26", uuid "564d7c38-f4ae-5702-c3c9-6f42ef95535c", host "esx02.test.local", resourcePool "resgroup-22", connectionState "Connected", powerState "PoweredOn", template "False", changeTracking "True", configVersion "vmx-08"

Далее следует масса информации про выбор прокси и доступных режимов работы. Всё это происходит под тегом [ProxyDetector]. Общий алгоритм таков: берём и проверяем возможность скачать диски поочередно в режимах SAN > HotAdd > NBD. Каким способом получилось, так и качаем. Начинается всё веселье в этом моменте:

[01.11.2020 05:00:24] <01> Info [ProxyDetector] Trying to detect source proxy modes for VM [vudc01], has snapshots:False, disk types:[Scsi: True, Sata: False, Ide: False, Nvme: False][01.11.2020 05:00:24] <01> Info [ProxyDetector] Host storage 'VMware ESXi 6.5.0 build-16207673' has 1 luns

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

[16.09.2020 00:08:01] <01> Info [ProxyDetector] Trying to detect source proxy modes for VM [TinyLinux2], has snapshots:False, disk types:[Scsi: True, Sata: False, Ide: False, Nvme: False][16.09.2020 00:08:11] <01> Info [ProxyDetector] Detecting storage access level for proxy [VMware Backup Proxy][16.09.2020 00:08:11] <01> Info Proxy [VMware Backup Proxy] - is in the same subnet as host [VMware ESXi 6.7.0 build-16[16.09.2020 00:08:11] <01> Info [ProxyDetector] Detected mode [nbd] for proxy [VMware Backup Proxy]...[16.09.2020 00:08:13] <01> Info [ProxyDetector] Trying to detect target proxy modes, sanAllowed:False, vmHasSnapshots:True, diskTypes:[Scsi: True, Sata: False, Ide: False, Nvme: False], vmHasDisksWithoutUuid:False[16.09.2020 00:08:24] <01> Info [ProxyDetector] Detecting storage access level for proxy [10.1.10.6][16.09.2020 00:08:24] <01> Info [ProxyDetector] Detected mode [nbd] for proxy [10.1.10.6]

Какой прокси, в каком режиме и куда был назначен надо смотреть в логе каждой таски по фразе Preparing for processing of disk

[16.09.2020 01:03:28] <20> Info Preparing for processing of disk [shared-spbsupstg02-ds04] TinyLinux2/TinyLinux2.vmdk, resources: source proxy 'VMware Backup Proxy' and target proxy '10.1.10.6'[16.09.2020 01:03:28] <34> Info Processing disk '[shared-spbsupstg02-ds04] TinyLinux2/TinyLinux2.vmdk'[16.09.2020 01:03:28] <34> Info Using source proxy 'VMware Backup Proxy' and target proxy '10.1.10.6' for disk processing

Также полезное можно найти в логе /Utils/VMC.log. С ним только одна сложность: вся информация внутри представлена в виде ID. Никаких имён и человекочитаемых названий. Слава роботам!

[16.09.2020 04:05:40] <56> Info [ViProxyEnvironment] Initialization of ViProxyEnvironment for the proxy 10.1.10.6 (5c7f925e-999b-473e-9a99-9230f51d5ebb).

Если мы говорим про Direct SAN режим, то самое важное это корректность сопоставления LUNов с их номерами. В данном примере виден общий смысл происходящего: сначала получаем номера лунов, проверяем все подключённые к прокси луны на предмет нахождения идентичного и в случае успеха работаем с ним.

[04.06.2019 17:54:05] <01> Info [ProxyDetector] Searching for VMFS LUN and volumes of the following datastores: ['test_datastore'][04.06.2019 17:54:05] <01> Info [ProxyDetector] Datastore 'test_datastore' lun was found, it uses vmfs[04.06.2019 17:54:05] <01> Info [ProxyDetector] VMFS LUNs: ['NETAPP iSCSI Disk (naa.60a980004270457730244a48594b304f)'], NAS volumes: <no>...[04.06.2019 17:54:16] <01> Info [ProxyDetector] Proxy [VMware Backup Proxy]: Detecting san access level[04.06.2019 17:54:16] <01> Info [ProxyDetector] Proxy [VMware Backup Proxy]: disks ['6000C29C75E76E488EC846599CAF8D94566972747561','6000C29EA317A4903AFE2B7B038D3AD6566972747561','6000C29274D8E07AAE27F7DB20F38964566972747561','60A980004270457730244A48594B304F4C554E202020','6000C29EE0D83222ED7BFCB185D91117566972747561','6000C292083A3095167186895AD288DB566972747561','6000C2950C4F2CB5D9186595DC6B4953566972747561','6000C29BF52BB6F46A0E6996DA6C9729566972747561']...[04.06.2019 17:54:16] <01> Info [ProxyDetector] Proxy VMware Backup Proxy disk: , disk inquiry: SCSI Unique ID 60A980004270457730244A48594B304F4C554E202020 is accessible through san for ESXi with vmfs lun: NETAPP iSCSI Disk (naa.60a980004270457730244a48594b304f)

Эти же номера можно проверить самим. В vSphere клиенте в разделе Host > Configure > Storage devices, а в Windows посмотреть в стандартный Disk Manager. Все номера должны совпадать.

Репозиторий

В отличие от бекапа, реплика хранится непосредственно на сторадже хоста. Репозиторию Veeam отводится роль хранителя метаданных. Под каждое задание создаётся своя папка, где хранятся .vbk файлы, содержащие так называемые дайджесты. Чтобы найти конкретный, открываем лог таски и ищем [DigestsRepositoryAccessor]. Получаем путь, название репозитория и ID.

[15.09.2020 05:44:54] <19> Info [DigestsRepositoryAccessor] Creating new digests storage at [E:\Replicas\Replication_Job_4_7b409570-c4e1-424f-a0c5-b0b6e6e47272_vm-34412\2020-09-15T024444.vbk].[15.09.2020 05:33:54] <21> Info Setting repository 'Backup Repository 1' ('adf7fbb6-0337-4805-8068-77960414f406') credentials for backup client.

Если репозиторием выступает сетевая шара, то будет написан её путь:

[15.09.2020 06:50:53] <41> Info [DigestsRepositoryAccessor] Creating new digests storage at [\\172.17.12.57\test\Replicas\Replication_Job_4_7b409570-c4e1-424f-a0c5-b0b6e6e47272_vm-34432\2020-09-15T035033.vbk]

Если углубиться в поисках, то по Setting repository можно найти не только ID и название, но и под какой учёткой мы туда ходим. Если вы используете не одну учётку для всего на свете, то запросто можно промахнуться в визарде и долго искать причину, почему не удаётся подключиться к серверу.

[15.09.2020 06:50:02] <20> Info Setting repository 'DD share' ('36a89698-2433-4c1a-b8d3-901d9c07d03a') credentials for backup client.[15.09.2020 06:50:02] <20> Info Creds user name: ddve\sysadmin[15.09.2020 06:50:02] <20> Info Setting share creds to [\\172.17.12.57\test]. CredsId: [66de1ea7-7e89-48f6-bc73-61a4d1a7621e][15.09.2020 06:50:02] <20> Info Setting share creds to [\\172.17.12.57\test]. Domain: [ddve], User: [sysadmin]

WAN акселераторы

Получившая недавно второе рождение функция, которая бывает особенно актуальна для реплик. Проверить, работают акселераторы или нет, можно, найдя в логе джобы флаг <UseWan>. А по строке Request: SourceWanAccelerator можно получить информацию об ID используемых акселераторах.

[15.09.2020 05:32:59] <01> Info - - Request: SourceWanAccelerator: [WanAccelerator '8f0767e1-99ab-4050-a414-40edc5bebc39'], TargetWanAccelerator: [WanAccelerator '22fa299c-8855-4cf8-a6c7-6e8587250750'][15.09.2020 05:32:59] <01> Info - - - - Response: Subresponses: [Wan accelerator],[Wan accelerator]

В таск логе имена будут указаны уже в явном виде

[15.09.2020 05:33:54] <21> Info Using source WAN Accelerator KK-BB2[15.09.2020 05:33:54] <21> Info Using target WAN Accelerator 10.1.10.6

Что за второе рождение упоминалось в начале? Это так называемый High Bandwidth режим. Если раньше смысл от акселераторов был только на действительно медленных линках (очень медленных линках), то в v10 был введён новый режим, обеспечивающий прирост в производительности на скоростях до 100 Мб/с. Включается он отдельной галочкой, а в логах таски это видно вот по этим строкам:

 [15.09.2020 05:33:54] <21> Info Selecting WaTransport algorithm, input arguments: performance mode preferred: False, perf mode available on target WAN: False[15.09.2020 05:33:54] <21> Info Selecting WaTransport algorithm: selected classic mode

В первой строке указаны результаты проверки, включён ли необходимый режим на обоих WA мы видим, что нет, и выбираем классическую версию.

Просто полезные слова для поиска

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

Backup/Replication Job log

"> Error" или "> Warning" здесь что-то произошло, на что точно надо обратить внимание. Не обязательно всё сломалось именно тут, но что-то здесь точно произошло. Возможно даже пошло не так, как планировалось.

Job Options: здоровенная XML, где перечислены все настройки задания. После неё обычно идёт раздел VSS Settings, где перечислены настройки VSS.

[RetentionAlgorithm] момент отрабатывания ретеншн алгоритма. Тут удаляются ставшие ненужными точки или синтезируются новые.

[JobSession] Load: ботлнеки, про которые в нашем блоге есть отдельная статья.

Preparing point узнаём, в каком режиме создаётся бекап (инкремент, реверс инкремент или фул).

Starting agent узнаём, какой агент когда был запущен, и по его ID идём читать соответствующий ему лог.

VMware Job

[ProxyDetector] весь процесс выбора рабочих прокси и режима транспорта. Технически, в Hyper-V будет всё то же самое, только с гораздо меньшим количеством деталей.

[SanSnapshots] блок создания и работы с SAN-снапшотами.

VM task детальная информация о каждой конкретной машине в задании.

Hyper-V Job

VM tasks в отличие от VMware тут не будет исчерпывающей информации, однако как отправная точка для поиска истины самое то.

VM guest info много информации о гостевой машине и самом хосте. Однако имя машины надо предварительно посмотреть в секции Creating task, которая немного выше.

Task log

Starting Disk можно узнать, когда началась обработка конкретного диска. Очень полезно, если у машины их много, включён parallel processing и всё несколько запутано.

Operation was canceled by user где-то рядом ещё должно быть Stop signal has been received. Указывает на реальное время остановки бекапа и может означать всё что угодно. Если время подозрительно красивое, вроде 06:00:00, а юзер мамой клянётся, что ничего не трогал, то 99,99% установлено Backup Window и ваше время истекло.

Starting agent опять же, получаем ID нужного агента и далее смотрим прицельно.

Preparing oib указывает, готовится ли бекап машины в инкрементальном виде или фул.

.source. shows показывает, на каком сервере будет запущен передающий агент (Source Proxy).

.target. показывает, на каком сервере будет запущен принимающий агент (Repository/Target proxy).

VMware Task

VM information: Практически вся информация, которую можно узнать про целевую машину.

[VimApi] Create или [VimApi] Remove создание и удаление снапшотов. Через [VimApi] делается ещё несколько действий, так что не удивляйтесь.

Hyper-V Task

Files to process краткий список того, что будет забекаплено.

[RTS] весь процесс создания снапшотов и их удаления.

Agent log

Err | или WARN| то же самое, что и > Error > Warning. В Err действительно есть пробел перед палочкой, это не опечатка.

Traffic size размер всей переданной информации.

stat размер файла бекапа.

Backup service log

== Name показывает абсолютно все джобы и их текущее состояние (работает или остановлена). Между == и названием два пробела.

[Scheduler] Ready to start jobs: список джоб, которые будут запущены в соответствии с расписанием.

by user эта пометка делается, если юзер что-то сделал сам.

Backup copy job log

[OibFinder] покажет вам, какие репозитории и точки восстановления были исключены из обработки. Иногда даже может сказать, почему.

[CryptoKeyRecryptor] позволит понять, менялся ли на этом проходе юзер-пароль или энтерпрайз-ключ.

Surebackup

Backup point или Replica point время, когда была создана проверяемая точка.

[<vm name>] [PowerOnVm] [StableIp] моменты включения и выключения машин в лаборатории.

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

Поэтому, если есть вопросы, то добро пожаловать в комментарии. Если есть предложение по написанию подобной статьи на какую-то конкретную тему адрес тот же, комментарии.

Засим позвольте откланяться и до новых встреч.

Подробнее..

Перевод Как в Smarkets улучшили мониторинг для своих Kubernetes-кластеров

17.11.2020 10:12:56 | Автор: admin
Прим. перев.: автор этой статьи ведущий инженер по инфраструктуре в Smarkets, что позиционирует себя как одну из самых прибыльных [по доходам на каждого сотрудника] компаний в Европе. Работая с большой и чувствительной к мониторингу инфраструктурой на базе Kubernetes, инженеры компании нашли своё счастье с VictoriaMetrics, которая помогла им решить проблемы с Prometheus, возникшие после добавления новых K8s-кластеров.

Мониторинг внутренних endpoint'ов и API Kubernetes может быть проблематичным, особенно если стоит задача использовать автоматизированную инфраструктуру как сервис. Мы в Smarkets еще не достигли этой цели, но, к счастью, уже довольно близки к ней. Я надеюсь, что наш опыт в этой области поможет и другим реализовать нечто подобное.

Мы всегда мечтали о том, чтобы разработчики прямо из коробки получали возможность мониторинга для любого приложения или сервиса. До перехода на Kubernetes эта задача выполнялась либо с помощью метрик Prometheus, либо с помощью statsd, который пересылал статистику на базовый хост, где она конвертировалась в метрики Prometheus. Наращивая применение Kubernetes, мы начали разделять кластеры, и нам захотелось сделать так, чтобы разработчики могли экспортировать метрики напрямую в Prometheus через аннотации к сервисам. Увы, эти метрики были доступны только внутри кластера, то есть их нельзя было собирать глобально.

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

Отправная точка


Для метрик, связанных с Kubernetes, мы используем два сервиса, предоставляющих метрики:

  • kube-state-metrics генерирует метрики для объектов Kubernetes на основе информации от API-серверов K8s;
  • kube-eagle экспортирует метрики Prometheus для podов: их request'ы, limit'ы, использование.

Можно (и в течение некоторого времени мы делали это) выставлять сервисы с метриками за пределы кластера или открывать прокси-подключение к API, однако оба варианты не были идеальны, поскольку замедляли работу и не обеспечивали должную независимость и безопасность систем.

Обычно разворачивалось решение для мониторинга, состоящее из центрального кластера из Prometheus-серверов, работающих внутри Kubernetes и собиравших метрики с самой платформы, а также внутренние метрики Kubernetes с этого кластера. Основная причина, по которой был выбран такой подход, состояла в том, что в процессе перехода на Kubernetes мы собрали все сервисы в одном и том же кластере. После добавления дополнительных Kubernetes-кластеров наша архитектура выглядела следующим образом:



Проблемы


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

При анализе 2-часового блока Prometheus:

  • 1,3 млн метрик;
  • 383 имени лейблов;
  • максимальная кардинальность на метрику 662 000 (больше всего проблем именно из-за этого).

Столь высокая кардинальность преимущественно связана с выставлением наружу таймеров statsd, включающих HTTP-пути. Мы знаем, что подобная реализация не идеальна, однако эти метрики используются для отслеживания критических ошибок в канареечных развертываниях.

В спокойное время собиралось около 40 000 метрик в секунду, однако их число могло вырастать до 180 000 в отсутствии каких-либо проблем.

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

Другая проблема состояла в том, что в условиях, когда на каждом экземпляре Prometheus хранились данные за три месяца, время запуска (WAL replay) оказывалось очень высоким, и это обычно приводило к тому, что тот же самый запрос направлялся на второй экземпляр Prometheus и ронял уже его.

Чтобы устранить эти проблемы, мы внедрили Thanos и Trickster:

  • Thanos позволил хранить меньше данных в Prometheus и сократил число инцидентов, вызванных чрезмерным использованием памяти. Рядом с контейнером Prometheus Thanos запускает sidecar-контейнер, который складирует блоки данных в S3, где их затем сжимает thanos-compact. Таким образом, с помощью Thanos'а было реализовано долгосрочное хранение данных за пределами Prometheus.
  • Trickster, со своей стороны, выступил обратным прокси и кэшем для баз данных временных рядов. Он позволил нам закэшировать до 99,53% всех запросов. Большинство запросов поступает от панелей мониторинга, запущенных на рабочих станциях/ТВ, от пользователей с открытыми контрольными панелями и от алертов. Прокси, способный выдавать только дельту во временных рядах, отлично подходит для подобной нагрузки.



У нас также начали возникать проблемы при сборе kube-state-metrics из-за пределов кластера. Как вы помните, частенько приходилось обрабатывать до 180 000 метрик в секунду, а сбор тормозил уже при выставлении 40 000 метрик в единственном ingressе kube-state-metrics. У нас установлен целевой 10-секундный интервал для сбора метрик, а в периоды высокой нагрузки этот SLA часто нарушался удаленным сбором kube-state-metrics или kube-eagle.

Варианты


Размышляя над тем, как улучшить архитектуру, мы рассмотрели три различных варианта:

  1. Prometheus + Cortex (https://github.com/cortexproject/cortex);
  2. Prometheus + Thanos Receive (https://thanos.io);
  3. Prometheus + VictoriaMetrics (https://github.com/VictoriaMetrics/VictoriaMetrics).

Подробную информацию о них и сравнение характеристик можно найти в интернете. В нашем конкретном случае (и после тестов на данных с высокой кардинальностью) явным победителем оказалась VictoriaMetrics.

Решение


Prometheus


Пытаясь улучшить описанную выше архитектуру, мы решили изолировать каждый кластер Kubernetes как отдельную сущность и сделать Prometheus его частью. Теперь любой новый кластер идет со включенным из коробки мониторингом и метриками, доступными в глобальных dashboard'ах (Grafana). Для этого сервисы kube-eagle, kube-state-metrics и Prometheus были интегрированы в кластеры Kubernetes. Затем Prometheus конфигурировался с помощью внешних лейблов, идентифицирующих кластер, а remote_write указывал на insert в VictoriaMetrics (см. ниже).

VictoriaMetrics


База данных временных рядов VictoriaMetrics реализует протоколы Graphite, Prometheus, OpenTSDB и Influx. Она не только поддерживает PromQL, но и дополняет его новыми функциями и шаблонами, позволяя избежать рефакторинга запросов Grafana. Кроме того, ее производительность просто потрясает.

Мы развернули VictoriaMetrics в режиме кластера и разбили на три отдельных компонента:

1. VictoriaMetrics storage (vmstorage)


Этот компонент отвечает за хранение данных, импортированных vminsert. Мы ограничились тремя репликами этого компонента, объединенными в StatefulSet Kubernetes.

./vmstorage-prod \        -retentionPeriod 3 \        -storageDataPath /data \        -http.shutdownDelay 30s \        -dedup.minScrapeInterval 10s \        -http.maxGracefulShutdownDuration 30s

VictoriaMetrics insert (vminsert)


Этот компонент получает данные от deployment'ов с Prometheus и переправляет их в vmstorage. Параметр replicationFactor=2 реплицирует данные на два из трех серверов. Таким образом, если один из экземпляров vmstorage испытывает проблемы или перезапускается, все равно остается одна доступная копия данных.

./vminsert-prod \        -storageNode=vmstorage-0:8400 \        -storageNode=vmstorage-1:8400 \        -storageNode=vmstorage-2:8400 \        -replicationFactor=2

VictoriaMetrics select (vmselect)


Принимает PromQL-запросы от Grafana (Trickster) и запрашивает исходные данные из vmstorage. В настоящее время у нас выключен кэш (search.disableCache), поскольку в архитектуре присутствует Trickster, который и отвечает за кэширование; поэтому надо, чтобы vmselect всегда извлекал последние полные данные.

/vmselect-prod \        -storageNode=vmstorage-0:8400 \        -storageNode=vmstorage-1:8400 \        -storageNode=vmstorage-2:8400 \        -dedup.minScrapeInterval=10s \        -search.disableCache \        -search.maxQueryDuration 30s

Общая картина


Текущая реализация выглядит следующим образом:



Примечания к схеме:

  • Production-кластер и кластеры со вспомогательными сервисами более не хранят данные мониторинга. Цель данного конкретного изменения состояла в том, чтобы ограничить глобальную функцию кластеров K8s и предотвратить каскадные отказы. В случае выхода из строя какого-либо кластера важно иметь доступ к метрикам и логам, которые помогут установить суть проблемы. Совместная работа сервисов в одних и тех же кластерах повышала вероятность каскадных отказов и затрудняла диагностику первопричины сбоя.
  • Каждый deployment в составе кластера K8s идет вместе с локальным Prometheus'ом, который собирает исключительно внутренние метрики и отправляет их в VictoriaMetrics insert в инфраструктурном кластере Kubernetes.
  • В инфраструктурном кластере Kubernetes работают два deployment'а с Prometheus, выполняющие разные функции. Вообще говоря, подобная схема не была строго обязательной, однако она придала процессу мониторинга Kubernetes необходимую согласованность, так что любые изменения теперь автоматически и единообразно применяются ко всем кластерам. Global Prometheus теперь отвечает только за сбор метрик с экземпляров EC2, с colocation-хостинга и любых других не-Kubernetes-сущностей.

Заключение


Ниже приведены метрики, которые в настоящее время обрабатывает VictoriaMetrics (итоговые данные за две недели, на графиках показан промежуток в два дня):



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

Это отличный показатель, но есть еще несколько моментов, которые мы планируем улучшить в ближайшие месяцы:

  • Снизить кардинальность метрик, улучшив интеграцию statsd.
  • Сравнить кэширование в Trickster и VictoriaMetrics нужно оценить влияние каждого решения на эффективность и производительность. Есть подозрение, что от Trickster можно вообще отказаться, ничего не потеряв.
  • Превратить Prometheus в stateless-сервис пока он работает как stateful, однако для этого нет особых причин. Мы до сих пор используем лейблы на основе постоянного сетевого имени, предоставляемого StatefulSet'ом, так что об этом придется помнить (как и о pod disruption budgets).
  • Оценить работу vmagent компонента VictoriaMetrics для сбора метрик с Prometheus-совместимых exporter'ов. Учитывая, что на данный момент наш Prometheus только этим и занимается, это перспективное направление для улучшения. В будущем vmagent позволит полностью отказаться от Prometheus (его бенчмарки выглядят многообещающе!).

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

P.S. от переводчика


Читайте также в нашем блоге:

Подробнее..

Обзор инструментов для chaos engineering в Kubernetes. Часть 1 kube-monkey, chaoskube, Chaos Mesh

23.11.2020 12:04:01 | Автор: admin


Хаос-инжиниринг для Kubernetes становится всё популярнее, и это закономерно: ведь такая инфраструктура создавалась быть готовой к тому, чтобы в любой момент что-нибудь отстрелило. А значит это замечательное свойство надо проверять в реальных проектах.

Благо, уже сегодня можно найти не одно Open Source-решение, помогающее в подобных экспериментах. Представляем вашему вниманию их обзор. Он получился весьма объёмным, поэтому был разбит на две части: в этой мы рассмотрим три популярных проекта.

Предыстория


История chaos engineering начинается в 2011, когда в компании Netflix решили, что только избыточная и распределенная инфраструктура может дать действительно высокую отказоустойчивость. Для того, чтоб непрерывно убеждаться в том, что это действительно так, они и создали Chaos Monkey.

Суть этой обезьяны сводилась к тому, чтобы регулярно убивать один из экземпляров какого-то сервиса, будь то виртуальная машина или контейнер. Увеличение размера инфраструктуры и эволюция привели к появлению Chaos Kong сервиса, который отрубает один из трёх регионов AWS. Вот это по-настоящему масштабная проверка отказоустойчивости!

В целом же, список доступных действий для хаос-инжиниринга значительно шире, чем простое убийство сервисов. Главная цель этой новой науки обнаружение вероятных проблем, которые либо не устраняются должным образом, либо не обнаруживаются / не воспроизводятся постоянно. Поэтому убийством не ограничиваются: нужно ещё умело вставлять палки в колёса и дисковую подсистему, рвать сетевые соединения и поджаривать CPU с памятью особо продвинутые могут даже фрагментировать страницы памяти в ядре запущенного pod'а (как это вообще, cgroups?).

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

Возвращаясь же к классическому Chaos Monkey: эта утилита была создана и используется в Netflix. В настоящий момент она интегрирована с платформой непрерывной доставки Spinnaker, поэтому работает с любым поддерживаемым там бэкендом: AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry.

Однако такое, казалось бы, удобство таит в себе обратную сторону. Установка/настройка Chaos Monkey для Kubernetes (в связке со Spinnaker) по своей простоте очень далека от привычного Helm-чарта Далее будут рассмотрены инструменты для chaos engineering, созданные специально для K8s.

1. kube-monkey



Один из самых старых проектов среди изначально ориентированных на Kubernetes: первые публичные коммиты в его репозитории состоялись в декабре 2016 года. Попробуем его сразу в деле на развёрнутом deployment'е nginx из пяти реплик, попутно рассказывая о возможностях.

Итак, вот манифест для испытаний:

---apiVersion: v1kind: Namespacemetadata:  name: test-monkeysspec:  finalizers:  - kubernetes---apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  namespace: test-monkeysspec:  selector:    matchLabels:      app: nginx  replicas: 5  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx:1.16        ports:        - containerPort: 80---

Готовый чарт с kube-monkey самый простой вариант установки и запуска утилиты:

$ git clone https://github.com/asobti/kube-monkey$ cd kube-monkey/helm

Немного модифицируем команду из README.md, чтобы обезьянка жила в своём namespace и начинала работу в двенадцать ночи по Москве, заканчивая за час до полуночи (такое расписание подходило нам на момент написания статьи):

$ helm install -n kubemonkey --namespace kubemonkey --set config.dryRun=false --set config.runHour=0 --set config.startHour=1 --set config.endHour=23 --set config.timeZone=Europe/Moscow --set config.debug.schedule_immediate_kill=true --set config.debug.enabled=true kubemonkey

Теперь можно натравить обезьянку на nginx с помощью лейблов. Kube-monkey работает по принципу opt-in, т.е. взаимодействует только с теми ресурсами, которые разрешено убивать:

$ kubectl -n test-monkeys label deployment nginx kube-monkey/enabled=enabled$ kubectl -n test-monkeys label deployment nginx kube-monkey/kill-mode=random-max-percent$ kubectl -n test-monkeys label deployment nginx kube-monkey/kill-value=100$ kubectl -n test-monkeys label deployment nginx kube-monkey/identifier=nginx

Пояснения по лейблам:

  • Второй и третий (kill-mode, kill-value) говорят kube-monkey убивать случайное количество pod'ов из StatefulSets/Deployments/DaemonSets, вплоть до 100%.
  • Четвёртый (identifier) определяет уникальный лейбл, по которому kube-monkey найдёт жертв.
  • Пятый (mtbf mean time between failure) определяет, сколько дней должно пройти между убийствами (по умолчанию равен единице).

Сразу появляется ощущение, что пять лейблов это многовато, чтобы просто взять и кого-то поубивать Кроме того, есть pull request о том, чтобы mtbf указывать не только в днях (но и в часах, например, чтобы чаще совершать злодеяния). Однако он висит с 5 февраля без движения, что печально.

Ок, посмотрим на логи обезьянки и увидим в конце:

I0831 18:14:53.772484       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:15:23.773017       1 schedule.go:64] Status Update: Generating schedule for terminationsI0831 18:15:23.811425       1 schedule.go:57] Status Update: 1 terminations scheduled todayI0831 18:15:23.811462       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:16:11 +0300 MSKI0831 18:15:23.811491       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.********** Today's schedule **********k8 Api Kind    Kind Name        Termination Time-----------    ---------        ----------------v1.Deployment    nginx        08/31/2020 21:16:11 +0300 MSK********** End of schedule **********

Ура! Chaos-monkey нашла deployment и запланировала убийство одной или более из его реплик. Но что же это и почему?

E0831 18:16:11.869463       1 kubemonkey.go:68] Failed to execute termination for v1.Deployment nginx. Error: v1.Deployment nginx has no running pods at the moment

Посмотрим внимательно в мануал ещё раз и увидим (с устаревшим apiVersion, к сожалению):

For newer versions of kubernetes you may need to add the labels to the k8s app metadata as well.

---apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: monkey-victim  namespace: app-namespace  labels:    kube-monkey/enabled: enabled    kube-monkey/identifier: monkey-victim    kube-monkey/mtbf: '2'    kube-monkey/kill-mode: "fixed"    kube-monkey/kill-value: '1'spec:  template:    metadata:      labels:        kube-monkey/enabled: enabled        kube-monkey/identifier: monkey-victim[... omitted ...]

Ок, изменяем наш шаблон с удалением deployment'а на:

---apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  namespace: test-monkeys  labels:    kube-monkey/enabled: enabled    kube-monkey/identifier: nginx    kube-monkey/kill-mode: random-max-percent    kube-monkey/kill-value: "100"    kube-monkey/mtbf: "1"spec:  selector:    matchLabels:      app: nginx  replicas: 5  template:    metadata:      labels:        app: nginx        kube-monkey/enabled: enabled        kube-monkey/identifier: nginx    spec:      containers:      - name: nginx        image: nginx:1.16        ports:        - containerPort: 80---

Теперь все получилось:

I0831 18:24:20.434516       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:24:50.434838       1 schedule.go:64] Status Update: Generating schedule for terminations    ********** Today's schedule **********    k8 Api Kind    Kind Name        Termination Time    -----------    ---------        ----------------    v1.Deployment    nginx        08/31/2020 21:25:03 +0300 MSK    ********** End of schedule **********I0831 18:24:50.481865       1 schedule.go:57] Status Update: 1 terminations scheduled todayI0831 18:24:50.481917       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:25:03 +0300 MSKI0831 18:24:50.481971       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.I0831 18:25:03.540282       1 kubemonkey.go:70] Termination successfully executed for v1.Deployment nginxI0831 18:25:03.540324       1 kubemonkey.go:73] Status Update: 0 scheduled terminations left.I0831 18:25:03.540338       1 kubemonkey.go:76] Status Update: All terminations done.I0831 18:25:03.540499       1 kubemonkey.go:19] Debug mode detected!I0831 18:25:03.540522       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 sec

Ок, работает хорошо и весьма конкретно. Хотя настраивается сложнее, чем могло быть, не очень гибко, да и функций совсем мало. Бывают и странности в работе:

I0831 18:30:33.163500       1 kubemonkey.go:19] Debug mode detected!I0831 18:30:33.163513       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:31:03.163706       1 schedule.go:64] Status Update: Generating schedule for terminationsI0831 18:31:03.204975       1 schedule.go:57] Status Update: 1 terminations scheduled today    ********** Today's schedule **********    k8 Api Kind    Kind Name        Termination Time    -----------    ---------        ----------------    v1.Deployment    nginx        08/31/2020 21:31:45 +0300 MSK    ********** End of schedule **********I0831 18:31:03.205027       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:31:45 +0300 MSKI0831 18:31:03.205080       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.E0831 18:31:45.250587       1 kubemonkey.go:68] Failed to execute termination for v1.Deployment nginx. Error: no terminations requested for v1.Deployment nginxI0831 18:31:45.250634       1 kubemonkey.go:73] Status Update: 0 scheduled terminations left.I0831 18:31:45.250649       1 kubemonkey.go:76] Status Update: All terminations done.I0831 18:31:45.250828       1 kubemonkey.go:19] Debug mode detected!

2. chaoskube



Эта утилита тоже может похвастать длинной историей: первый её релиз состоялся в ноябре 2016 года. У chaoskube есть готовый чарт и хороший мануал по нему. По умолчанию запускается в режиме dry-run, поэтому никто не пострадает.

Запустим на простом deployment'е с nginx, живущем в пространстве имен test-monkey, и укажем опцию про создание RBAC (потому что у роли default нет нужных прав):

$ helm install --name chaoskube --set dryRun=false --set namespaces="test-monkeys" --set rbac.create=true --set rbac.serviceAccountName=chaoskube stable/chaoskube

дело сразу пошло!

$ kubectl -n default logs chaoskube-85f8bf9979-j75qmtime="2020-09-01T08:33:11Z" level=info msg="starting up" dryRun=false interval=10m0s version=v0.14.0time="2020-09-01T08:33:11Z" level=info msg="connected to cluster" master="http://personeltest.ru/aways/10.222.0.1:443" serverVersion=v1.16.10time="2020-09-01T08:33:11Z" level=info msg="setting pod filter" annotations= excludedPodNames="<nil>" includedPodNames="<nil>" labels= minimumAge=0s namespaces=test-monkeystime="2020-09-01T08:33:11Z" level=info msg="setting quiet times" daysOfYear="[]" timesOfDay="[]" weekdays="[]"time="2020-09-01T08:33:11Z" level=info msg="setting timezone" location=UTC name=UTC offset=0time="2020-09-01T08:33:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-8kf64 namespace=test-monkeystime="2020-09-01T08:43:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-t7wx7 namespace=test-monkeystime="2020-09-01T08:53:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-8fg9q namespace=test-monkeystime="2020-09-01T09:03:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-wf5vg namespace=test-monkeys

Конфигурировать можно всё, что может потребоваться: часовой пояс, временные исключения, лейблы, по которым ищутся pod'ы-жертвы, и исключения.

Подводя быстрый итог: хороший, удобный и простой инструмент, но, как и kube-monkey, умеет только убивать pod'ы.

3. Chaos Mesh



Chaos Mesh состоит из двух компонентов:

  1. Chaos Operator оператор хаоса, основной компонент, который в свою очередь состоит из:
    1. controller-manager (управляет Custom Resources),
    2. chaos-daemon (привилегированный daemonset с возможностями управления сетью, cgroups и т.д.),
    3. sidecar-контейнера, динамически вставляемогов целевой pod, чтобы вмешиваться в I/O целевого приложения.
  2. Chaos Dashboard веб-интерфейс для управления и мониторинга хаос-оператора

Проект входит в CNCF и разработан китайской компанией PingCAP, которая известна своей распределённой, Open Source, cloud-native SQL-базой данных для аналитики в реальном времени TiDB (мы писали про её собрата TiKV, тоже входящего в число проектов CNCF).

Итак, хаос-оператор использует CRD для определения объектов хаоса. Всего их шесть типов: PodChaos, NetworkChaos, IOChaos, TimeChaos, StressChaos и KernelChaos. А вот какие доступны действия (эксперименты):

  • pod-kill убийство pod'а;
  • pod-failure недоступность pod'а некоторое (определённое) время;
  • container-kill убийство одного из контейнеров pod'а;
  • netem chaos сетевые проблемы, задержки, повторы пакетов;
  • network-partition эмуляция распада сети на сегменты;
  • IO chaos проблемы с диском и чтением/записью;
  • time chaos искажение показателя текущего времени в pod'е;
  • cpu-burn стресс CPU;
  • memory-burn стресс памяти;
  • kernel chaos жертва получит ошибки ядра, фрагментацию страниц памяти, проблемы с блочным I/O.

Объявляя любой из нужных нам Custom Resource, мы можем указать в нём типы действий, лейблы и селекторы для определения целевых namespace или конкретных pod'ов, а также длительность и расписание проведения экспериментов в общем, всё необходимое для планирования веселья.
Звучит очень интересно, да? Давайте попробуем! Документация по установке снова с Helm.

Не забудем указать --set dashboard.create=true, чтобы получить панели с красивыми графиками! Через пару минут мы получаем целое пространство имён из повелителей хаоса пока ещё бездействующих, но уже готовых к работе:

$ kubectl -n chaos-testing get poNAME                                       READY   STATUS    RESTARTS   AGEchaos-controller-manager-bb67cb68f-qpmvf   1/1     Running   0          68schaos-daemon-krqsh                         1/1     Running   0          68schaos-daemon-sk7qf                         1/1     Running   0          68schaos-daemon-wn9sd                         1/1     Running   0          68schaos-dashboard-7bd8896c7d-t94pt           1/1     Running   0          68s

Для изучения и демонстрации работы chaos-mesh подготовлен подробный мануал, в котором можно увидеть многочисленные возможности оператора. С технической точки зрения, внутри репозитория (https://github.com/chaos-mesh/web-show) находится Deployment тестового приложения на React с сервисом, которому скриптом передаётся IP-адрес pod'а kube-controller-manager (первый из списка, если у нас мультимастер, или просто единственный). После запуска этот pod начинает непрерывно пинговать pod controller-manager'а и визуализировать на графике этот ping.

В нашем случае удобнее выпустить этот график наружу через Ingress, а не команду из deploy.sh (nohup kubectl port-forward svc/web-show --address 0.0.0.0 8081:8081). Поэтому мы просто применяем Deployment и Service из репозитория и объявляем любой Ingress просто для того, чтобы можно было попасть в приложение снаружи.



Приятный график. Судя по сегменту ST, у пациента острый инфаркт! Стоп, это же не кардиограмма А теперь можно применить заклинание хаоса, слегка подкорректировав его для пущей красоты:

apiVersion: chaos-mesh.org/v1alpha1kind: NetworkChaosmetadata:  name: web-show-network-delayspec:  action: delay # the specific chaos action to inject  mode: one # the mode to run chaos action; supported modes are one/all/fixed/fixed-percent/random-max-percent  selector: # pods where to inject chaos actions    namespaces:      - test-monkeys    labelSelectors:      "app": "web-show"  # the label of the pod for chaos injection  delay:    latency: "50ms"  duration: "10s" # duration for the injected chaos experiment  scheduler: # scheduler rules for the running time of the chaos experiments about pods.    cron: "@every 60s"

Результат ожидаемая нами красивая пила, сигнализирующая о том, что netem chaos уже работает. И вот тут уже точно инфаркт.



А вот как выглядит chaos-dashboard:



Визуализация событий:



Подробности о конкретном эксперименте:



Есть даже веб-редактор Custom Resources, но встроенной авторизации к нему нет (обязательно надо закрывать авторизацией!):



В завершении обзора этого проекта стоит упомянуть, что недавно (25 сентября 2020 г.) у Chaos Mesh произошло знаменательное событие релиз версии 1.0.

Продолжение следует


Во второй части статьи будут рассмотрены Litmus Chaos, Chaos Toolkit, игровые варианты хаос-инжиниринга в Kubernetes и некоторые другие проекты, а также подведён общий итог.

P.S.


Читайте также в нашем блоге:

Подробнее..

Observability система для микросервисов на примере Instana, часть 1

27.11.2020 10:16:55 | Автор: admin

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

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

Мыпрошли этот путь больше года назад, когда изучали инструменты, которые стоит использовать вне стандартной связки Prometheus + Grafana. Обзор получился объемным, поэтому разбили надве части.

Архитектура и установка агентов

Архитектурно продукт Instana состоит изсервера иагентов, собирающих данные. Устанавливается один агент нахост, который контролирует сам хост, все контейнеры иприложения, работающие нахосте. Основные данные, которые собирает продукт это метрики приложений иинфраструктурных компонентов (прокси-серверы, СУБД, кэш, очереди итд), трейсы приложений, логи иошибки приложений. Поддерживается 200+ технологий для сбора данных. Помимо этого, впродукте присутствуют модули EUM End User Monitoring для сбора данных производительности сконечных пользователей, взаимодействующих сприложениями через веб-браузеры инативные мобильные приложения для iOS иAndroid.

Сервер Instana backend, накоторый агенты отсылают данные, предоставляется помодели SaaS, атакже доступен вварианте on-premise для компаний, нежелающих использовать облачную модель размещения.

Мониторинг микросервисных приложений начинается сустановки агента Instana. Агент устанавливаются одной командой. Вразделе установки мывыбираем нужную нам платформу, идалее генерируется скрипт для его установки. Среди поддерживаемых агентом платформ есть Linux, Unix, Windows, Kubernetes всех мастей иоблачные среды AWS, Azure иGoogle Cloud.

Мастер выбора платформы и варианта установки агента Мастер выбора платформы и варианта установки агента

Наскриншоте представлен один извариантов установки агента вKubernetes кластер helm chart. Также можно установить агента спомощью Kubernetes Operator или daemonset.yaml. После того, как агенты установятся внаш кластер, мысможем посмотреть накарту нашей инфраструктуры вInstana.

Первое знакомство с продуктом Infrastructure Map

Карта объектов инфраструктурыКарта объектов инфраструктуры

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

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

Внашем случае мывидим, что агент обнаружил Docker контейнеры, Node.JS приложения, MongoDB, SpringBoot Java приложения иеще много других компонентов.

Свойства выбранного Node.JS приложения на карте инфраструктурыСвойства выбранного Node.JS приложения на карте инфраструктуры

Выбрав одну из коробок от пиццы мы получаем сводную информацию об этом компоненте. Выбрав Node.JS приложение shop-frontend мы видим версию приложения, ID процесса, аргументы запуска и другую информацию. Для детального анализа компонента по клику доступен дашборд с инфраструктурными метриками, но мы поговорим об этом позже. Также мы видим полную инфраструктурную географию этого компонента указание на детали расположения компонента в инфраструктуре. В нашем случае Node.JS приложение связано с процессом node, процесс находится в контейнере, контейнер в k8s поде, под находится на ноде k8s, а нода k8s обслуживается хостом. Для каждого из этих уровней доступны свои собственные дашборды и соответствующие метрики.

Свойства выбранного Docker контейнера на карте инфраструктурыСвойства выбранного Docker контейнера на карте инфраструктуры

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

Карта инфраструктуры с контейнерами, сгруппированными по Kubernetes namespaceКарта инфраструктуры с контейнерами, сгруппированными по Kubernetes namespace

Автоматический распределенный трейсинг гетерогенных приложений

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

С точки зрения трейсинга продукт поддерживает следующие языки разработки и технологии:

Технологии, поддерживаемые в Instana с точки зрения трейсингаТехнологии, поддерживаемые в Instana с точки зрения трейсинга

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

Для этого перейдем в раздел Applications на вкладку Services где мы видим все наши сервисы и их основную информацию - имя и тип сервиса, количество обнаруженных endpoints и ключевые метрики - количество вызовов, время исполнения и процент ошибок.

Список обнаруженных сервисовСписок обнаруженных сервисов

Мы также можем увидеть связи микросервисов между собой, визуализируя на карте взаимодействия микросервисов. Такая карта строится автоматически, всегда в актуальном состоянии и отображает связи и данные о сервисах в реальном времени. На карте отображается и состояние здоровья сервиса. Красный - есть критичная проблема, желтый - есть проблема, отсутствие индикации, значит сервис здоров.

Карта взаимодействия сервисовКарта взаимодействия сервисов

При выделении любого из сервисов система сразу же подсветит все сервисы, с которыми выбранный сервис напрямую взаимодействует, также отобразит его KPI.

Карта взаимодействия сервисов, выбор сервисаКарта взаимодействия сервисов, выбор сервиса

Управление группами сервисов

С приходом микросервисов стало сложно определять, что именно теперь называть приложением. Ведь в одно приложение могут входить десятки разных сервисов, причем один и тот-же сервис может быть частью двух и более разных приложений. Как раз для логического разделения сервисов на приложения в продукте используется Application Perspective группа логически объединенных по какому-то критерию сервисов.

Группы сервисов - Application Perspective Группы сервисов - Application Perspective

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

Настройка Application Perspective и критерии объединения сервисовНастройка Application Perspective и критерии объединения сервисов

Например, мы можем сгруппировать сервисы по окружениям - production, stage, dev, test. Можем сгруппировать по Kubernetes namespace или deployments, по тегам, по продукту, команде и так далее. После создания Application Perspective сервисы сгруппируются по указанным параметрам и, в случае появления нового сервиса с параметрами, подходящими под настроенные критерии, сервис автоматически добавится в заданную группу.

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

Дашборд KPI приложения (группы сервисов)Дашборд KPI приложения (группы сервисов)

В Instana Application Perspectives используются для анализа KPI на дашбордах, ролевого управления доступом, алертинга, фильтрации данных на многих экранах. Функционал Application Perspectives позволяет различным командам разработки и эксплуатации эффективно фокусироваться на своих участках и не мешать друг другу.

Анализ KPI сервисов и endpoints

Мы уже увидели карту взаимосвязи сервисов, возможности их группировать, но часто нам нужно проанализировать ключевые метрики производительности одного конкретного сервиса. В Instana для каждого обнаруженного сервиса создается дашборд с ключевыми метриками и данными о связанных объектах инфраструктуры.

Мы переходим на такой дашборд просто выбрав интересующий нас сервис на карте сервисов или в списке. Давайте посмотрим на сервис eum-shop это HTTP сервис Spring Boot приложения.

Дашборд KPI сервисаДашборд KPI сервиса

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

Список обнаруженных endpoint у сервиса, в данном случае он один Список обнаруженных endpoint у сервиса, в данном случае он один

Аналогично представлен дашборд с метриками производительности каждого endpoint для сфокусированного анализа.

Дашборд endpoint KPI Дашборд endpoint KPI

Интеграция с CI/CD маркеры релизов в графиках мониторинга

Когда мы анализируем метрики производительности сервисов и видим деградацию в производительности рост процента ошибок, увеличение времени исполнения важно знать, а не связано ли это с выпуском нового релиза? Для визуализации такой информации предусмотрена возможность сообщать в Instana о том, что был сделан релиз приложения или какого-то одного сервиса, сделав простой вызов к API, например, из CI-пайплайна.

Маркер релиза на дашборде сервисаМаркер релиза на дашборде сервиса

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

Список недавних релизов для анализа производительностиСписок недавних релизов для анализа производительности

Инфраструктурный контекст и взаимосвязь сервисов

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

На вкладке Upstream, мы видим все сервисы, которые вызывают сервис eum-shop, и их ключевые метрики.

Upstream сервисы и их метрики - кто обращается к eum-shopUpstream сервисы и их метрики - кто обращается к eum-shop

Аналогично в Downstream мы видим все сервисы, которые вызывает сервис eum-shop, и их ключевые метрики - обычно это не только http сервисы, но и базы данных, кэш, очереди и тд..

Downstream сервисы и их метрики - к кому обращается eum-shopDownstream сервисы и их метрики - к кому обращается eum-shop

Instana не только определяет связи сервисов между собой, но и связи с компонентами инфраструктуры. Эта информация доступна по клику кнопки Stack.

Связь сервиса с объектами инфраструктурыСвязь сервиса с объектами инфраструктуры

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

Перейдя на вкладку Kubernetes мы увидим сущности Kubernetes, с которыми связан наш сервис pod, Kubernetes service, namespace, deployment, node.

Связь сервиса с объектами KubernetesСвязь сервиса с объектами Kubernetes

Перейдя на вкладку Application мы увидим группы приложений, в которые входит анализируемый сервис (как мы помним один сервис может входить в несколько приложений) и их сводные KPI.

Связь сервиса с приложениямиСвязь сервиса с приложениями

Нам доступен drill down на дашборды связанных компонентов для детального анализа их производительности. Давайте проанализируем наш Kubernetes кластер.

Мониторинг Kubernetes

Instana очень тесно интегрируется с Kubernetes и собирает все ключевые метрики и данные нашего кластера. Для анализа Kubernets представлен отдельный дашборд, где мы можем наблюдать метрики всего кластера, по нодам, подам, namespace, deployments, k8s сервисам и так далее.

Дашборд Kubernetes кластераДашборд Kubernetes кластера

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

Дашборд одного из Kubernetes namespaceДашборд одного из Kubernetes namespace

Инфраструктурные метрики Kubernetes уже есть в Prometheus + Grafana, но с помощью Instana мы получили связь еще и трейсов с сущностями Kubernetes. C Kubernetes дашборда мы переходим к анализу вызовов, которые были в этом namespace. Кликнув на кнопку Analyze calls мы попадем в новый раздел - раздел Аналитика.

Раздел Аналитика

Раздел Аналитика с группировкой вызовов по Kubernetes Service и KPIРаздел Аналитика с группировкой вызовов по Kubernetes Service и KPI

В разделе Аналитика нам сразу доступны данные и метрики всех вызовов, которые были отфильтрованы по нашему namespace robot-shop и сгруппированы по Kubernetes сервисам. В этом разделе доступен анализ всех вызовов, выбор и визуализация метрик, отображение диаграмм для верхнеуровнего анализа. При необходимости можно очень гибко отфильтровать и отсортировать вызовы и трейсы, чтобы найти именно нужный.

Давайте сгруппируем наши вызовы по имени endpoint:

Группировка вызовов по одному из тэгов - названию endpointГруппировка вызовов по одному из тэгов - названию endpoint

И посмотрим на графике к каким endpoints больше всего идет вызовов.

График количества вызовов, сгруппированных по endpoint nameГрафик количества вызовов, сгруппированных по endpoint name

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

Список вызовов по заданным фильтрам и их длительностьСписок вызовов по заданным фильтрам и их длительность

Как мы видим, у нас применился новый фильтр endpoint.name. Но в данном случае нас интересуют только вызовы с ошибкой. Одним кликом мыши добавляем фильтр erroneous = true для получения всех вызовов с ошибкой - Instana записывает каждый вызов и все они доступны для анализа.

Список вызовов, содержащих ошибку и их длительностьСписок вызовов, содержащих ошибку и их длительность

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

Детальный анализ трейсов

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

Детальный анализ трейсаДетальный анализ трейса

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

Дерево вызовов - последовательность спанов в трейсе и их данныеДерево вызовов - последовательность спанов в трейсе и их данные

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

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

Связь спана с объектами инфраструктурыСвязь спана с объектами инфраструктуры

Анализ инфраструктурных метрик

Перейдя к Spring Boot приложению мы попадаем на соответствующий дашборд с метриками Spring Boot. Instana автоматически собирает ключевые метрики с более чем 200 технологий, например, nginx, redis, postgresql, mysql, rabbitmq, elasticsearch, kaffka, Docker, IIS, Tomcat и многих других. Для каждой из технологий доступен автоматически настроенный дашборд.

Метрики Spring Boot приложенияМетрики Spring Boot приложения

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

Расположение приложения в инфраструктуреРасположение приложения в инфраструктуре

Например, анализируя метрики Spring Boot приложения нам может быть удобно сразу посмотреть метрики JVM, в которой запущено наше приложение информация о threads, heap memory, memory pools, garbage collection и другие:

Метрики JVMМетрики JVM

Перейдя на уровень хоста мы уже видим другие ключевые метрики использование CPU, памяти, TCP активность и так далее.

Метрики машиныМетрики машины

Алертинг и выявление аномалий

Из коробки мы получили более 230 правил для определения состояния здоровья различных компонентов инфраструктуры и обнаружения аномалий в KPI сервисов и endpoints. Для каждого сервиса и каждого endpoint Instana определяет нормальное поведение KPI метрики (baseline) и, в случае отклонения от baseline, мы получим соответствующие оповещение.

Список правил алертинга и выявления аномалийСписок правил алертинга и выявления аномалий

Можно добавлять свои собственные правила. В качестве критерия могут быть метрики объектов инфраструктуры, Kubernetes, приложений и сервисов, пользовательского опыта.

Все что относится к результатам мониторинга состояния здоровья, мы можем увидеть в разделе Events.

Раздел Events - сработавшие правилаРаздел Events - сработавшие правила

В Instana существует несколько типов событий:

  • Changes изменения компонентов инфраструктуры. Мы видим события онлайн/офлайн компонентов (включение и отключение процессов, контейнеров и тд), были ли изменения в конфигурации компонента.

  • Issue сработало правило определения состояния здоровья. Правила могут быть как встроенные, так и созданные самостоятельно.

  • Incidents события самого высокого уровня, которые открываются, когда проблемой затронуты наши конечные пользователи или возникла критичная проблема в нашей инфраструктуре. В инцидент объединяются и коррелируются все сопутствующие события на основе анализа графа связей сервисов и компонентов инфраструктуры.

Перейдя ко вкладке Incidents мы увидим все инциденты.

ИнцидентыИнциденты

И кликнув на один из них, мы сможем детально его проанализировать.

Детали одного из инцидентовДетали одного из инцидентов

Что мы видим в инциденте? Время начала и завершения инцидента, сколько событий с ним связано (15), сколько было затронуто компонентов инфраструктуры и сервисов (5) и сами события. Давайте разберемся, с чего начался наш инцидент.

Детали одного из событий в инцидентеДетали одного из событий в инциденте

Началось все с того, что на сервисе catalogue-demo резко увеличилось количество вызовов с ошибками. В деталях события мы получили говорящую подсказку This can be a sign of a problem on one side of the connection. На графике метрики рейт ошибочных вызовов, которая связана с этим событием, мы видим, что у нас 60% вызовов вдруг стали содержать ошибки. Прямо отсюда мы можем перейти к анализу вызовов в разделе Аналитика, где будут автоматически применены все фильтры, связанные с этим событием вызовы будут отфильтрованы по сервису catalogue-demo и добавлен фильтр erroneous.

Что случилось дальше? За счет того, что Instana определила взаимосвязи сервисов и компонентов инфраструктуры, мы можем увидеть, как проблема на одном сервисе, затронула другие сервисы. Мы видим список других сервисов и компонентов инфраструктуры и их проблемы на одних резко уменьшилось количество вызовов, на других также увеличился процент ошибок, на третьих увеличилось среднее время транзакций.

Список событий в инциденте и его причинаСписок событий в инциденте и его причина

В расследуемом инциденте есть событие Abnormal termination процесса базы данных MySQL. Собственно это и есть причина нашего инцидента.

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

С точки зрения каналов оповещения, то есть того, куда мы можем получать алерты, помимо самого интерфейса продукта, доступны следующие варианты:

Список каналов для отсылки оповещенийСписок каналов для отсылки оповещений

Что мы получили в итоге

Подведем промежуточные итоги первой части обзора. С помощью Instana мы смогли:

  • наблюдать всегда актуальную картину нашей инфраструктуры и взаимосвязи всех микросервисов между собой;

  • без каких-либо усилий по настройке собрать и использовать метрики со всех компонентов, таких как JVM, Node JS приложение, Nginx, Redis, Postgresql, сами Docker контейнеры, кластер и все сущности Kubernetes;

  • автоматически получить распределенный трейсинг для PHP, Python, Node JS, Java и других сервисов;

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

Микросервисное приложение, которое использовалось в этом обзоре, вы можете запустить самостоятельно: https://github.com/instana/robot-shop

Для изучения продукта Instana на собственной инфраструктуре доступен бесплатный триальный период: https://www.instana.com/trial/

В следующей части обзора Instana мы рассмотрим функционал End User Monitoring для контроля производительности приложений у реальных пользователей в браузерах и в нативных мобильных приложениях.

Спасибо за внимание.

Подробнее..

Контейнеризация понятным языком от самых азов до тонкостей работы с Kubernetes

27.11.2020 18:11:38 | Автор: admin


Чем контейнеры отличаются от виртуальных машин, почему Docker настолько популярен, что такое Kubernetes и в чём его преимущества и недостатки. В интервью АйТиБороде СТО Слёрма Марсель Ибраев и старший инженер Southbridge Николай Месропян рассказали о контейнеризации понятным языком. Мы перевели интервью в текст для тех, кому лень смотреть.
Мне не лень смотреть, мне лень читать


Разница между контейнеризацией и виртуализацией


Что такое виртуализация?


Виртуализация появилась как средство уплотнения окружений на одном и том же железе. Сначала программный продукт выполнялся на железном сервере. Потом, чтобы иметь возможность поселять в одно и то же железо больше клиентов, чтобы максимально полно утилизировать производительные мощности, придумали виртуализацию. Теперь на одном и том же железе можно держать несколько окружений. В зависимости от среды, опять же. Есть полностью проприетарные решения, такие как vmware vsphere, есть опенсорсные решения, как QEMU KVM, на основе которого Red Hat делает свой коммерческий гипервизор Red Hat Virtualization. На платформе Windows есть Hyper-V.


Благодаря виртуализации мы получаем возможность более полно утилизировать ресурсы железа. Но при этом речь идёт о полной изоляции: в виртуальной машине полностью изолированное ядро, все библиотеки, строго ограниченные ресурсы по процессору и памяти.


Ядра разделяются физически или можно виртуально разделить там одно физическое ядро на несколько при виртуализации?


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


Что такое контейнеры и контейнеризация, и чем отличаются?


Детали зависят от операционной системы, на которой выполняется контейнер, но вообще контейнер делит с хостом ядро, пространство памяти ядра, и своё у контейнера только пользовательское окружение. Первая широко распространенная технология контейнеризации в Linux это OpenVZ, которая потом превратилась в коммерческий продукт Virtuozzo. Мы много работали и работаем с OpenVZ. У нас клиентские окружения жили в контейнерах OpenVZ, пока мы не перешли на более современные технологии.


То есть контейнер от виртуальной машины отличается только тем, что в контейнере общее адресное пространство?


Нет. Виртуальная машина изолируется полностью средствами процессора (технологии Intel, AMD, VMX).


Контейнер работает на ядре хостовой операционной системы и использует для изоляции возможности не железа, а операционной системы, так называемое пространство имён. Если мы говорим о Docker, как о наиболее распространённой сейчас технологии виртуализации, используются так называемые cgroups в ядре Linux.


Контейнер это продолжение виртуализации? То есть это технология, которая является преемником виртуализации?


Нет. Они ни в коем случае не конкурируют. Они занимают совершенно разные ниши в использовании.


Тогда почему их постоянно сравнивают? И постоянно есть вопрос, что лучше виртуализация или контейнеризация?


С моей точки зрения сравнить контейнеризацию и виртуализацию нельзя. Это сравнение теплого с мягким.


Где лучше использовать виртуализацию, а где контейнеризацию? Для как разработчика нет разницы: и то, и то используется для развертывания приложений. Два-три приложения ты фигачишь контейнером. Ты можешь виртуальных машин столько создать, и в каждой из них запустить своё приложение. В чем разница для обычных девелоперов?


Для тебя виртуальная машина это обычная изолированная операционная система, целиком: своё ядро, свой init, systemd и так далее. Чем она отличается от контейнера с точки зрения потребления ресурсов? Тем, что она полностью занимает все ресурсы, под неё выделенные. То есть, есть механизмы, когда можно динамически, то есть в зависимости от потребления процессами внутри виртуальной машины, освобождать память на хосте или занимать её. Но это всё полумеры.


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


Если мы говорим о Docker (а в рамках разговора мы не сможем обсудить все варианты контейнеризации), то он рассчитан на то, что в одном контейнере работает одно приложение.


Возвращаясь к твоему первому вопросу, разница вот в чём. Допустим, если у тебя на хосте Linux или VMware, то виртуальная машина у тебя может быть Windows. Если у тебя в контейнере Linux, то у тебя и снаружи Linux. Потому что мы в первую очередь пользуемся для изоляции не средствами железа, не средствами гипервизора, а средствами операционной системы cgroups и namespace.


Почему контейнеры разворачиваются быстрее? Потому что они маленькие, содержат в себе там одно приложение? Почему быстрее развернуть контейнер, нежели зафигачить, законфигурировать?


Виртуалка сама по себе большая, так как содержит целую операционную систему. Если нам нужно развернуть виртуальную машину, то нужно нести с собой и ядро, и всё пользовательское окружение, и какой-то запас места (потому что динамически оно с хостом шариться в общем случае не может). Я не видел линуксовую виртуальную машину весом меньше 10 Гб, и это без данных. Потом к ней еще нужно прицепить диски для данных, в зависимости от того, что будет внутри.


Если говорить о контейнерах, есть разные дистрибутивы, в том числе специально созданные для контейнеризации, тот же Alpine Linux, который в голом виде весит 20 или 50 Мб в зависимости от версии. То есть ничего не весит, собственно говоря.


Виртуалка тянет полностью всю операционку, а когда Docker создаешь, ты тянешь только какие-то небольшие пакеты?


Нет. Чтобы создать Docker-контейнер ты должен собрать образ. Ты берёшь какой-то базовый образ, тот же Alpine, CentOS или Ubuntu. В него с помощью специальных команд зашиваешь свое приложение и выгружаешь уже туда, где оно будет работать.


То есть все равно ты в контейнере используешь полноценную операционку? Вот тот же образ Alpine Linux.


Она может быть сильно порезаной по сравнению с операционной системой, которую ты засовываешь в виртуальную машину.


Но потенциально ты можешь и полноценный Linux запустить в контейнере?


Потенциально да, можешь.


Но смысла в этом, наверное, нет.


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


Один контейнер? А это не слишком жирно использовать для одного приложения, ну пусть и урезанную, но операционную систему?


Когда нужна изоляция это не слишком жирно.


Понял. Есть ли какие-то еще инструменты, которые позволяют сделать что-то похожее на контейнеризацию, но не контейнеризация?


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


Почему Docker захватил весь рынок? Вот ты говорил, что было решение какое-то изначально в Linux?


Нет. Оно занимало и занимает совершенно другую нишу. Docker захватил весь рынок в первую очередь потому, что он первым начал использовать технологии namespace и cgroups для, так сказать, народа. Понизил порог вхождения в эти технологии до того, чтобы можно было выйти на широкий рынок, на широкого пользователя.


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


А как тут обстоит дело с дебагом твоего кода, логированием и всем остальным? Со стороны кажется, что это сложновато: нужно залезть внутрь какого-то контейнера, который представляет из себя урезанную операционку


Когда работаешь с контейнерами, в принципе не обязательно думать, что это операционка, не операционка. Там начинается другой мир. Да, к нему надо привыкнуть, но с дебагом, логированием проблем нет никаких, потому что хорошим тоном считается писать все логи в stdout/stderr контейнера, а не в файлики внутри него.


Docker-контейнер знаменит тем, что он одноразовый. Он запустился, а после того, как ты контейнер удаляешь, если ты специально никаких мер не предпринимал, чтобы сохранить в нём данные, у тебя всё удаляется. Поэтому все логи обычно пишут в stdout/stderr, средствами Docker или внешних утилит экспортируют их в ElasticSearch, ClickHouse или какие-то другие системы хранения логов и централизованно уже с ними работают. В первую очередь потому, что контейнеров много. Контейнеров в сетапах могут быть десятки, сотни, тысячи и десятки тысяч.


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


Что насчет контейнеризации в Windows? Насколько я помню, там если не всё очень плохо, то не всё так просто, как на Linux.


Там, действительно, очень сложно. Я ни в коем случае не Windows-админ, знаком поверхностно. Но насколько я знаю, нативная контейнеризация в Windows есть. Есть средства изоляции и по ресурсам, и по пространствам имен, сетевые пространства имен, для памяти, под файлы и так далее. То есть можно Windows запустить как контейнер Windows. Это Windows Server Containerization, если я не ошибаюсь (Windows-админы, не обессудьте).


Но если мы говорим о том, чтобы запускать Docker в Windows, то здесь начинаются пляски. Docker это технология Linux, потому что использует специфические средства для изоляции, для создания контейнеров.


Когда контейнер выполняется, он не представляет собой некий образ. Когда выполняется виртуальная машина это образ, внутри которого своя файловая система, свои разделы, где всё это нарезано и всё это варится. Когда выполняется контейнер, для операционной системы это просто набор ограничений. Когда мы смотрим на процесс виртуальной машины с хоста, мы видим один процесс. В винде это Microsoft Hyper-V, в Linux это QEMU KVM, в vSphere это тоже один процесс. Когда мы смотрим с хоста на контейнер, то видим дерево процессов.


Но почему мы образы передаем друг другу? Я приложение запаковываю в Docker, и мы девелоперы передаём друг другу образы.


Образ это то, из чего контейнер запускается. А с точки зрения хоста это дерево процессов, которые ограничены через встроенные средства ограничения, то есть через namespace и cgroups. Это я к тому, что Docker по своей сути линуксовый.


А почему нельзя было сделать универсальное решение, чтобы оно и для Linux, и для винды работала? Там нет общих API или в Linux есть что-то, чего нет


Ядро-то разное.


Архитектура разная, да?


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


Я думал, что ядра macOS и Linux очень похожи.


Нет. macOS больше UNIX-like, нежели Linux. Потому что, как известно GNU is not UNIX (рекурсивный акроним). А macOS внутри более, так сказать, близка к юниксам. И там нет таких механизмов, как в Linux. Они развиваются независимо.


Docker и для Windows, и для macOS это чужеродное тело, которое запускается в линуксовой виртуалке.


Получается, чтобы запустить контейнер, нужно запустить еще и виртуалку?


Мы запускаем линуксовую виртуалку, а уже в ней мы уже запускаем эти контейнеры. Docker Desktop скрывает от пользователя все сложные процессы, но внутри все равно остаются всякие. Ну не то, чтобы это очень неэффективно. Если вам нужно разрабатывать что-то под Docker, но у вас только Windows или только macOS, то это позволяет работать, да. Но в продакшене с нагрузками так ничего толком не запустишь.


Я понял, что ты в основном с Linux работаешь, но вдруг ты слышал про WSL (Windows Subsystem for Linux)?


Разумеется, я на OpenNET читаю об этом всём и удивляюсь.


А может ли эта штука запустить контейнеры нативно? Я просто не знаю, она тоже под виртуалкой?


Насколько я понимаю, WSL это Wine наоборот. То есть трансляция вызовов API в нативные для винды. Если у нас Wine это трансляция вызовов виндового API для ядра Linux, то WSL это наоборот. И поэтому средств изоляции там ядерных линуксовых нет. Поэтому увы, увы.


Про оркестрацию


Скажем, у нас микросервисная архитектура, и не одно приложение, а много всего: 10, 20, 40, 100 микросервисов. Руками их конфигурировать совсем не прикольно. Как с этим разбираются?


Да, это вполне типовая ситуация. Сейчас особенно, потому что стильно, модно, молодежно. Постепенно приложение обрастает логикой, микросервисов становится больше и больше. И одного Docker, и даже Docker Compose уже становится мало. Ну и плюс ко всему, наверное, еще хочется какую-то отказоустойчивость, чтобы это на нескольких серверах работало. Возможно, какой-то Service Discovery и прочее.


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



Марсель Ибраев, СТО Слёрм


Docker Compose не позволяет нам ничего делать? Ведь это тоже средство управления несколькими контейнерами.


Docker Compose, как минимум, не позволяет запускать проект на нескольких серверах. То есть это все равно все-таки история про одну ноду. Поэтому, да.


ОК. Что придумано? Что есть сейчас, чтобы это все делать?


Сразу нужно сказать, что инфраструктурный стандарт это всё-таки Kubernetes. Штука, которая в свое время была произведена в Google. И Google по зову сердца, по доброте своей решил поделиться с миром.


Есть ещё ряд решений, например, Docker Swarm, Mesos, OpenShift и другие, но всё-таки наиболее популярен и пользуется спросом Kubernetes. Компании, которые задумываются о том, что им нужен оркестратор, в первую очередь смотрят на Kubernetes.


Где обычно применяются оркестраторы, в частности Kubernetes?


Да, это очень важный вопрос. Дело в том, что Kubernetes все проблемы не решает. Компания работает, работает, у них всё плохо (как правило, плохо с процессами) они такие: Блин, Kubernetes классная штука. Давайте её себе поставим у нас всё сразу станет хорошо! Но становится сильно хуже.


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


Если вы небольшая компания или если у вас монолит, и вы такие: Сейчас мы его в куб засунем и все станет хорошо! Нет, не станет.


Kubernetes работает только с контейнерами Docker и с их оркестрацией?


Kubernetes работает с контейнерами, но не только с Docker. У Kubernetes есть такая штука, которая называется Container Runtime Interface. В принципе, все системы контейнеризации, которые сейчас есть и которые поддерживают Container Runtime Interface, могут работать с Kubernetes. Например, rkt.


Сейчас возникло движение энтузиастов, которые выкорчевывают Docker из Kubernetes и используют что-то другое. Потому что Docker тоже не без проблем. Главная проблема Docker это его демон, который имеет свойство зависать, особенно при большой нагрузке. Но зачем демон, если у нас уже есть Kubernetes, есть достаточно зрелая инфраструктура и нам надо просто какое-то место для запуска контейнеров.


Дополнительный демон по сути не нужен. В эту сторону движение сейчас активно идёт, но, я думаю, дойдёт не быстро. Устоявшееся мнение, что контейнеры равно Docker, будет держаться долго.


А что может быть использовано вместо Docker более оптимальным путем?


Оптимально пока сложно сказать, потому что у конкурентов Docker есть свои минусы. К примеру, containerd не имеет нормального средства управления им. К слову, с версии 1.11, кажется, под капотом Docker containerd и работает. По сути, сейчас Docker выполняет роль обёртки над containerd, а там containerd, а внутри ещё runC, если уж совсем углубляться.


Кто-то говорит про Podman: делайте просто алиас Podman Docker, и можно сразу работать. Но тоже есть свои нюансы, поэтому мы в том числе пока работаем с Docker.


Расскажи подробнее, как вообще Kubernetes работает? Что у него происходит под капотом? Для начала уточним, Kubernetes это сервис или это какое-то ПО, которое можно ставить на сервера, или это и то и то?


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


Всегда нужно держать в голове, что Kubernetes это в первую очередь оркестратор контейнеров. Когда вы это понимаете, то вы понимаете, для чего он нужен.


Kubernetes состоит из нескольких компонентов, которые выполняют каждый свою роль (подробно о них ещё поговорим). Из этого вытекает две особенности:


  1. Компоненты друг друга не аффектят. Если один упал, то все остальные могут продолжить работать.
  2. Эти компоненты работают по pull-модели. Нет никакого центрального компонента, командира, который всем раздаёт команды, а как сдох, так все не знают что делать. Каждый компонент выполняет свою часть работы: сделал, завершил. Если он умер, ну значит этот кусочек не выполнится.

Теперь по поводу самих компонентов. Основной компонент это API-сервер. Это просто апишка, REST API (разработчики понимают, о чём речь): управление с помощью http-запросов, версионирование кстати тоже. Очень важно, что там есть версия API, при обновлении мы можем на эти версии API завязываться и за счёт этого обновляться менее болезненно. Есть API, с которым работают все: и клиент (мы, как оператор кластера), и компоненты остальные в том числе.


API-сервер работает с хранилищем, которое представляет из себя просто etcd. Etcd это key-value хранилище, то есть ключ-значение. Вот и API-сервер это единственный компонент, который с этим хранилищем взаимодействует.


Это какая-то разработка команды kubernetes?


Нет, это отдельная штука, очень древняя.


А почему её у Redis нет, например?


У Redis есть проблемы с многопоточностью, есть проблемы с кластеризацией (хотя они ее постепенно решают). А etcd штука древняя, все детские болезни там уже вылечены, и она достаточно такая отказоустойчивая.


Кстати, это хороший показатель, что если разработчики Kubernetes уже начиная с первых версий используют etcd, то, наверное, у себя его тоже можно использовать как key-value в кластер-режиме.


API-сервер единственный, кто с etcd работает, он записывает, считывает информацию. А в etcd у нас хранится всё. Там наши настройки кластера, манифесты всё, что мы делаем.


Мы как клиент хотим что-то создать, запустить приложение, и мы эту информацию передаем в API-сервер. Мы непосредственно это не делаем, конечно, там есть такая утилита, которая называется kubectl. С её помощью мы управляем всем кластером, делаем все операции, в том числе и запускаем приложения. Передаем yaml-манифест, где у нас в декларативном формате описано, как должно выглядеть приложение в кластере. Вот мы это передаем. Оно сохраняется в etcd и следующие компоненты постоянно смотрят в API-сервер.


Если немного углубиться, там есть подписка на событие и они по сути watch'ат. То есть никакого DDoS'а самого себя там нет. Следующий компонент, который берёт эту историю в работу это kube-controller-manager. По сути, мозг кластера Kubernetes. В него вшиты множество контроллеров: node-controller, endpoint-controller. Практически у всех абстракций, которые есть в Kubernetes, есть контроллер, и он вшит в этот бинарь. Эти контроллеры занимаются просто контролем вот этой абстракции: смотрят, есть ли новые, нужно ли что-то удалить и так далее.


Давай на примере. Если продолжать говорить о приложении, то контроллер, который отвечает за какое-то конкретное приложение, точнее за его манифест, за его абстракцию он видит, что мы что-то хотим создать, запустить. И он выполняет соответствующую работу, а именно дописывает манифест в etcd, обновляет информацию. Тут, конечно, без некоторого углубления нормально не объяснишь. Но есть такая абстракция, которая называется ReplicaSet. Она позволяет запускать приложение в нескольких инстансах. Через нее мы можем увеличивать, уменьшать количество реплик. И все здорово.


Это балансировка нагрузки?


Это просто контроль за количеством инстансов одного и того же приложения.


А зачем?


Чтобы иметь возможность в случае чего скейлить свое приложение или скейлить обратно. То есть хотим в три инстанса реплики просто пишем три у нас три инстанса.


Ну это очень похоже на балансировку нагрузок.


Балансировкой уже занимается другая абстракция, которая уже трафик распределяет на вот эти три инстанса.


То есть они в принципе могут в паре работать?


Да. Они в паре и работают.


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


Инстансы, которые запускает ReplicaSet, называются подами. В подах и работает наше приложение (про поды мы ещё поговорим).


И вот как раз, когда мы создаем, например, ReplicaSet, у нас есть такой ReplicaSet controller в этом контроллер-менеджере, который описание подов для ReplicaSet генерирует, и туда же, грубо говоря, в etcd через API-сервер скидывает.


Потом подключается следующий компонент. После того, как мы поняли, какое приложение нам нужно из скольких инстансов запускать, оно вот в etcd хранится этот манифест. Далее у нас идет такой компонент, который называется scheduler. Его роль достаточно проста. Он решает, на каких серверах это приложение надо запускать. Но делает это не просто так, у него есть свои алгоритмы принятия решения.


Ну в частности, он смотрит на ресурсы, то есть сколько ресурсов на ноде, если мы для этого приложения запрашиваем 1 ГБ ОЗУ, а на ноде только 512 свободны, он туда не отправляет.


Под приложением ты понимаешь Docker-контейнер с приложением?


Да, контейнер.


Контейнер с приложением каким-то.


Да.


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


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


На стабильность он не смотрит. Он смотрит в первую очередь на ресурсы. Какой смысл отправлять приложение на запуск туда, где их недостаточно. Смотрит ещё на priority class это такая штука, с помощью которой мы можем задать приоритет.


Например, в кластере два окружения: продакшн и стейджинг. Конечно, продакшн более важен. И для них мы priority class выставляем высокий. Для стейджинга мы можем поставить поменьше. Когда происходит авария, Kubernetes понимает, что часть серверов отвалилась (за это будет отвечать Node Controller, который контролирует жизнь нод), он принимает решение, что надо те поды, которые там были, запустить в живых серверах. Scheduler будет запускать в первую очередь поды продакшена.


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


А если не хватит под продакшн места?


Если не хватит, ну сорян. Поды будут висеть в pending, то есть ждать, когда появятся ресурсы. И scheduler назначает Если на такой низкий уровень опуститься, то в манифесте пода есть специальное поле, которое называется nodeName имя ноды. И вот пока scheduler не принял решение оно пустое. Scheduler говорит, что вот этот под, вот это приложение нужно запускать там на Node 2, и он эту информацию передает, API-сервер это записывает в etcd и в это поле вносит это имя. А далее в работу вступает последний компонент всей этой схемы, который называется kubelet.


Kubelet это компонент своего рода "node agent", то есть агент, который запущен на всех серверах кластера. Он тоже постоянно в API-сервер смотрит. И он видит, что появился под, то есть приложение, у которого в поле имя сервера написано его имя, там, где он работает. Он такой: Ага! Значит его нужно у себя запустить! Он видит, что у него запущено, и что от него хотят. Он передает Docker API, из манифеста считывает, что там конкретно нужно запустить, и говорит Docker, какой контейнер нужно запустить.


Kubelet, получается, замена Docker демона?


Вот в том то и дело, что не замена, к сожалению. Поэтому вот эти альтернативы и изобретаются, поэтому туда люди идут, потому что Docker демон висит. Но по сути да, он общается с Docker демоном по API, но без него вполне можно было обойтись. Причем он не просто их запускает, он постоянно смотрит за статусом, и статус этот передаёт в API-сервер.


Хелс-чек такой?


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


Ноды это всегда сервер или это может быть кластер серверов?


Ноды это место, где запущен Kubelet.


Это может быть виртуалка, как я понимаю?


Да, может быть виртуалка.


Ты сказал, что в результате этих действий мы получаем физически развёрнутое приложение. Kubelet посылает какие-то свои статусы, либо он просто stdout контейнера фигачит? К чему этот вопрос. Потому что, если у тебя приложение в stdout выдает логи, какой-то дебаг kubernetes как-то умеет это в одно место собирать и предоставлять в удобочитаемом виде, или это не его обязанность вообще?


В твоем вопросе, два вопроса скрыты. Статус самого контейнера (жив или не жив) берёт из Docker. Функционал приложения (работает ли оно) вот эти дебаг, логи, какие-то хелс-чеки это все тоже делает Kubelet, но для этого надо несколько строчек в манифест добавить и сказать, как именно проверять.


На данный момент поддерживается три возможности проверять приложение:


  1. http-get это http-запрос в контейнер на инпоинт, и мы видим, работает оно, не работает, отвечает, не отвечает. С 200 по 399 код это ок, если 301 даже редирект это ок. Если 404 это не ок. 500 тем более.
  2. exec мы внутрь контейнера делаем какой-то запрос, какую-то команду, проваливаемся. Например, select 1, проверяем, всё ли нормально с базой.
  3. tcp socket Kubelet просто проверяет доступные сокеты. Если все хорошо, то все хорошо.

Есть три типа проверки контейнеров: это liveness, readiness и startup пробы.


Liveness проба это контроль за жизнью приложения. Постоянно Kubelet смотрит, ходит и смотрит. Там гибкие настройки, можно написать, как часто ходить, как проверять и так далее.


Readiness проба проверяет, а готово ли приложение принимать трафик. Потому что разные истории могут быть, это могут быть разные инпоинты у приложения. Мы проверяем, работает ли приложение, готово ли оно принимать трафик.


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


На каком размере архитектуры может работать Kubernetes? Может ли он контролировать сразу миллион инстансов?


Насколько я помню из документации, это 5000+, что ли, нод. На одной ноде по умолчанию можно запустить 110 подов, 110 экземпляров приложения.


Под это экземпляр одного и того же приложения? Или могут быть два разных контейнера на одном серваке и это будет два разных пода?


Под это абстракция, в которой запускается приложение. Тут важно понять, что это не какая-то физическая оболочка, не какой-то процесс ещё один, это скорее именно абстракция, с которой работает Kubernetes.


Kubernetes не умеет работать с контейнерами. Мы не можем сказать: заскейль нам вот это приложение в трёх контейнерах. Мы можем только сказать: заскейль нам в трех подах. В поде может быть как один контейнер, так и несколько. То есть мы можем туда запихнуть, например, nginx и php-fpm в связке, и они будут скейлится по два контейнера в связке.


Но тут надо понимать, что хорошая практика засовывать в контейнер неделимые части приложения. Всё-таки, если 2-3 контейнера надо засовывать, то может, стоит ещё поиграться с логикой приложения. Обычно один контейнер засовывают и там есть еще второй, который сам запускается, это pause контейнер, который держит сетевой namespace, чтобы все контейнеры в поде были в одном namespace, и чтобы всё хорошо работало.


Это первая часть беседы. Во второй будет про хранение данных в Kubernetes и про Ansible. Не пропустите!


Вопросы задавал Лекс АйТиБорода iamitbeard

Подробнее..

53 совета как поднять нерабочую сеть

17.11.2020 12:21:43 | Автор: admin


Ноябрь месяц особенный. Целых два профессиональных праздника для российских безопасников: День специалиста по безопасности в России 12 ноября и Международный день защиты информации 30 ноября.


Находясь между этими датами, невольно задумываешься на тему: а что есть безопасность в принципе? И что приносит больший вред: внешние атаки или сумасшедшие ошибки, странные предрассудки и просто нежелание что-либо сделать хорошо?


Предлагаем вашему вниманию перечень вредных советов, надеюсь, они вам понравятся.


Для начала пример из жизни


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


Примечателен тот факт, что в сети ранее была создана вся необходимая структура для обеспечения стабильности, безопасности и т.д. В том числе закуплены коммутаторы L3, новенькие точки доступа Wi-Fi и много другого полезного.


Но вся эта техника просто не использовалась. А зачем? Никто этого не оценит. Зато быстро прибежавшего сисадмина сразу после телефонного звонка пользователи обязательно похвалят и даже угостят карамелькой. Пара новейших коммутаторов грустно лежала в коробке, потому что установить их было просто некому.


В итоге всё находилось в одной подсети. Ни о каких VLAN не могло быть и речи.


Разумеется, и СХД, и рабочие станции, и даже веб-сервер с внешним сайтом компании всё было в одной сети класса С. Все 254 адреса были давным-давно оприходованы. И когда возник дефицит IP адресов, то начальник отдела ИТ принял оригинальное решение: урезать диапазон динамических IP адресов и снизить время лизинга IP адресов на DHCP сервере до 1 секунды.
Таким образом, компьютеры тех сотрудников, кто приходили на работу пораньше, получали доступ к локальной сети, а опоздавшие или те, кто приходил ровно к началу рабочего дня курили бамбук. Классический вариант: кто раньше встал, того и тапки. Тем самым удалось и модернизации избежать, и дисциплину поднять, ведь теперь работники, мало того, что стараются прийти пораньше, так ещё и на работе задерживаются.
Но как же быть с теми хитрецами, кто не выключал компьютеры, уходя домой, чтобы сохранить доступ в сеть? Очень просто: все компьютеры, кроме ноутбуков топ-менеджеров в 22-00 выключались принудительно.


Кроссовый журнал не вёлся. Мало того, повсеместно применялись сплиттеры, когда два компьютера сотрудников подключались к сети через одну настенную розетку. Сплиттеры делались силами сотрудников ИТ отдела из обычных внешних телефонных розеток и хитрых патчкордов, где с одной стороны был RJ45, а с другой телефонный штекер.


К любым, даже самым простым мерам безопасности вроде обновить антивирусные базы этот начальник ИТ относился с опасением. Фразы у нас честная фирма, нам нечего скрывать и да кому мы нужны были главным определяющим фактором при принятии решений. Все работники имели права администратора на своем компьютере. Примерно треть пользователей администраторы домена. А вдруг ответственному сотруднику внезапно понадобится какой-нибудь информационный ресурс для работы? Пароли были самые простые. Пользователи ведь не должны напрягаться, чтобы запоминать сложные пароли? Сочетание 1234 уже считалось вполне нормальным.


Вы считаете это выдумкой? Или такое возможно только в маленьких компаниях вроде Я, секретарша и директор? Увы, этот пример целиком взят из жизни.


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


Почему руководство компании терпело этот кавардак? Все вокруг искренне считали, что без этого незаменимого сотрудника в этом хаосе больше никто не разберется. Поэтому уволить такого ценного кадра, чтобы сделать резервную копию (кстати, системы резервного копирования не было тоже, её пришлось бы строить с нуля) и потом всё отстроить заново никак не решались. Всё-таки бизнес простаивать будет, а так, пусть через пень колоду, но вроде пока ещё как-то работает...


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


Проектирование и документация


При построении сети не составляйте даже эскизного проекта. Все решения должны приниматься спонтанно.


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


Наличие документации совершенно не важно, лучше если её вообще не будет. И уж точно вас не должны волновать несоответствие в документации и того, что есть в реальности.


Логическая организация и сервисы


Не разделяйте сети. Не используйте VLAN. На самом деле это придумали те, кто просто хочет побольше заморочиться.


Не используйте STP и другие средства отказоустойчивости. Чем больше петель и обрывов тем круче сеть.


Никакого контроля за IP адресами. Пусть и сервер DHCP, и статические адреса берутся из одного диапазона адресов не глядя. Если кому-то не повезло и адреса совпали дело житейское. Повезет в следующий раз. И вообще, Что наша жизнь? Игра!


Не планируйте запас IP адресов на вырост. Помните, что простой сети класса С и любимой маски 255.255.255.0 хватит на все случаи жизни.


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


Оборудование


Не обращайте внимание на элементную базу. Качество монтажа, качество комплектующих вещи абсолютно незначимые.


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


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

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


Не используйте резервирование. Ничего страшного если что-то постоит без работы, кто-нибудь да отремонтирует.


Не заключайте договор о расширенной гарантии и поддержке. Сгорит значит сгорит. Нужно стоически принимать удары судьбы.


Не имейте спасательного фонда. Только с колес. Если что-то выйдет из строя всегда можно срочно купить устройство на замену, желательно за наличные из такого же хлама, что подвернется под руку.


Wi-Fi


При развертывании Wi-Fi не используйте гостевую сеть. Смело раздавайте всем на право и налево ключ от офисного Wi-Fi. Разумеется, пароль обязательно быть один на всех. Никаких RADUS, Dynamic Personal Pre-Shared Key (DPPSK) и прочих ненужных вещей!


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


Разместите точку единственную доступа в самом труднодоступном изолированном месте. Глухой подвал с железной дверь вполне подойдет.


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


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


Если начальство требует что-то сделать с Wi-Fi, который не ловит разместите несколько одинаковых точек доступа рядом друг другом. Не настраивайте никаких параметров для снижения взаимного влияния.


Не используйте никакие средства Wi-Fi роуминга. Контроллеры точек Wi-Fi (даже если за эту функцию не надо платить, и она уже есть в сетевом оборудовании) жутко обременительная вещь.


Никогда не используйте облачные решения для контроля точек доступа. Лучше всё настраивать вручную.


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


Не используйте PoE для питания точек доступа. Если розеток недостаточно или точки находятся в трудно доступных местах используйте обычные удлинители для электропитания. Хорошей идеей также будет втыкать удлинители электропитания один в другой, чтобы получить нужную длину. Если искрит значит работает!


Не используйте шифрование в Wi-Fi. Если этого требует начальство используйте самый простой вариант. Если ваша точка доступа всё ещё поддерживает WEP используйте именно это. А то вдруг кто-то придет с устаревшим ноутбуком, который поддерживает только этот вариант...


СКС и учет оборудования


Никакой маркировки кабелей! Забудьте про кроссовый журнал. Только по памяти или методом "тыка".


Совет: Чтобы узнавать, что куда подключено, лучше всего просто выдернуть патчкорд из порта, и подождать, кто прибежит. Так можно узнать не только какое оборудование висит на данном проводе, но и насколько оно важно для работы сети.

Не ведите никакого учета оборудования. Только то, что в голове, только по памяти. Если заставляют вести документацию смело пишите в ней что попало. И, конечно, не вздумайте использовать никакую централизованную облачную систему.


Всегда прокладывайте СКС самым дешевым и устаревшим кабелем. Помните, что категория 5 (не 5E, а именно чистая пятерка) на высоких скоростях работает ничуть не хуже, чем более современные 5E, 6, 6A, 7...


Покупайте только самые дешевые патчкорды.


Не используйте патчпанели. Лучше всего провод сразу из стены обжать и воткнуть в порт оборудования.


Старый разболтанный обжимной инструмент от неизвестного производителя это самый лучший вариант для оконцовывания кабелей. Не имейте ничего хорошего и надежного.


Безопасность


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


Не используйте VPN и любое другое шифрование трафика. Честным людям нечего скрывать.


Не читайте логи безопасности. Всё равно ничего полезного там не прочтете, а если прочтете, то всё равно не поймете.


В настройках безопасности используйте самый простой режим по умолчанию.


Используйте прямое подключение через Интернет. Никаких этих дурацких вещей вроде DMZ и тому подобного. Только сразу напрямую к серверам во внутренней сети. И никаких дополнительных средств защиты!


Используйте неизвестные программы от третьих лиц вместо фирменного ПО. Например, зачем использовать Zyxel One Network, если можно воспользоваться каким-нибудь левым сканером сети с хакерского сайта, желательно ещё и крякнутой версией.


Совет. Разумеется, это всё гораздо надежнее, чем использовать облачные решения, ведь там за безопасностью следят злые админы, а это добрые люди на форуме посоветовали. Поэтому в облако ни-ни.

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


Не используйте антиспам. Любая фильтрация нарушает свободу переписки. Вдруг прямо сейчас кто-то из сотрудников получит письмо о наследстве из Нигерии. Он непременно будет вам признателен за эту возможность.


Не проводите поведенческого анализа действий пользователей в сети. Пусть сотрудники качают всё, что им вздумается. Чем больше они скачают на компьютеры, тем меньше останется в Интернет, и ваша компания станет несомненно богаче.


Модернизация имеющейся сети


Всячески уклоняйтесь от модернизации. По большому счету не важно, какая пропускная способность сети. Ethernet HUB 10Mb/s ни в чем не уступает коммутатору L3 10 Gigabit Ethernet.


Совет 1. Если начальство всё же настаивает на модернизации сети, начните проводить плановые работы в самое неудобное время, например, в активные бизнес-часы. Посидят несколько часов без сети авось поумнеют и отвяжутся со своей модернизацией.

Совет 2. Составьте список из самого дорого оборудования (пусть даже вам не так нужен весь этот набор функций) и запросите для начальства счет с кругленькой цифрой. Они непременно откажутся от планов модернизации, увидев, как много денег им придется потратить.

При выполнении работ не составляйте никаких планов заранее. Всё должно происходить строго по наитию. Спонтанные решения всегда лучше тщательного предварительной проработки.


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


Не обновляйте firmware сетевого оборудования. Не используйте централизованную систему контроля версий прошивок.


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


Совет. Если установки не избежать, то по возможности оттяните её как можно дольше, когда новое оборудование уже изрядно устареет. Так вы всегда можете сказать: "Ну вот видите, поставили новое, а получился всё равно отстой".

Мониторинг


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


Не настраивайте никакого информирования: ни по почте, ни по СМС, ни-че-го Пока не знаете о проблеме и голова не болит.


Не используйте никакую удаленную систему управления. Только личный приход в серверную избавит вас от большинства проблем.


Работа с персоналом


Не определяйте даже примерно зоны ответственности. Пусть все отвечают за всё.


Настоящий профессионал всегда знает всё. Если человек говорит, что с чем-то до этого момента не сталкивался и ему надо почитать литературу это слабак, его надо немедленно уволить и нанять всезнайку. Эффект Даннинга-Крюгера выдумали просто так, для утешения неудачников.


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


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


Никогда ничего не проверяйте и не тестируйте. Помните, что настоящие профессионалы никогда не ошибаются.



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


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


Полезные ссылки


Telegram chat Zyxel


Форум по оборудованию Zyxel


Много полезного видео на канале Youtube

Подробнее..

Вышел Windows Terminal Preview 1.5

19.11.2020 10:11:44 | Автор: admin
Мы вернулись с очередным выпуском Windows Terminal! Терминал Windows перешел на версию 1.4 и включает функции, описанные в сообщении блога о версии 1.4. Windows Terminal Preview была переведена на версию 1.5 и включает функции, описанные ниже, в этой статье. Вы можете загрузить обе версии из Microsoft Store или со страницы выпусков GitHub. Давайте узнаем, что нового!



Полная поддержка гиперссылок


Мы улучшили функциональность гиперссылок, чтобы автоматически обнаруживать ссылки внутри вашего терминала. Эти ссылки активны и открываются в вашем браузере по умолчанию с помощью Ctrl + Click.



Звонок


Терминал Windows теперь поддерживает символ BEL. Вы можете включить или отключить звонок с помощью настройки профиля bellStyle.

"bellStyle": "audible","bellStyle": "none"

Поддержка эмодзи в значках профиля


Теперь вы можете использовать смайлики в качестве значков профиля во всем терминале, установив в качестве значка своего профиля смайлик.



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

Настройка порядка переключения вкладок


Параметр useTabSwitcher обновлен! Теперь вы можете указать mru или inOrder, что включит переключатель вкладок с перечислением вкладок либо в порядке их последнего использования, либо в порядке их расположения в терминале.

// Включает tab switcher"useTabSwitcher": "mru","useTabSwitcher": "inOrder"// Отключает the tab switcher"useTabSwitcher": "disabled"

Фоновое изображение


В настройку backgroundImage добавлена новая опция! Вы можете установить фоновое изображение на desktopWallpaper, которое установит фоновое изображение терминала в качестве обоев рабочего стола.

Режимы запуска фокусуровки


В настройку launchMode добавлены новые режимы запуска. Теперь вы можете указать терминал для запуска в режиме фокусировки или режиме максимальной фокусировки. Режим фокусировки скрывает вкладки и строку заголовка.

"launchMode": "focus","launchMode": "maximizedFocus"

Отключение анимаций


Мы добавили анимацию при создании и закрытии панелей. Если вы хотите отключить анимацию во всем приложении терминала, вы можете использовать глобальный параметр disableAnimations.

"disableAnimations": true

Примечание. Если у вас отключена анимация на уровне ОС, вы не увидите анимацию внутри терминала, если не установите для disableAnimations значение false.

Улучшения палитры команд


Reconfigured > prefix


Мы переключили префикс > в режим действия внутри палитры команд, что соответствует функциональности палитры команд VS Code. Обратный интервал удалит символ > и переведет вас в режим командной строки, позволяя запускать аргументы командной строки.



Кнопка назад


При входе во вложенное меню из палитры команд теперь можно вернуться к корневому меню, не выходя из палитры команд.



Поисковые запросы полужирным шрифтом


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



Новые действия


Текстовое поле переименования открытой вкладки


Теперь вы можете открыть текстовое поле переименования вкладки, используя действие openTabRenamer.



Масштаб панели


Вы можете использовать действие togglePaneZoom, чтобы развернуть панель так, чтобы она соответствовала всему содержимому окна терминала.



Исправление ошибок


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

Сравнение производительности систем виртуализации на macOS

24.11.2020 04:23:42 | Автор: admin
Привет, Хабр! Думаю, никто не будет отрицать, что виртуальные машины незаменимая в хозяйстве вещь. Ведь это значительно удобнее, чем ставить множество ОС на свой компьютер. Или я вот, например, был бы и рад debian себе поставить на ноутбук рядом с macOS, да под макбуки с драйверами там большие проблемы. И вот, когда у меня сломался ПК, на котором были винда с линуксом, я собрался настраивать виртуалки у себя на ноутбуке. А так как хочется комфортно работать в виртуальной системе, то в первую очередь я обращал внимание на производительность. Самым простым способом было попробовать всё самим, что я и сделал, и вот делюсь результатами.

Для тестирования взял последние стабильные версии трёх самых популярных решений VMware Fusion Pro 12.1.0 (17195230), Parallels Desktop 16.1.1 (49141) и Oracle VirtualBox 6.1.16 (r140961). VirtualBox бесплатный и open-source (GPL v2), Fusion и Parallels я тестировал в trial версии, потому что я бедный студент, у которого нет денег. У Fusion Pro есть 30 дней пробной версии, а у Fusion Player бесплатная лицензия для персонального использования, для получения которой надо зарегистрироваться и немного подождать (мне выдали license key за где-то за сутки). Parallels только платный (14 дней триала), из-за чего для меня он был вне конкурса, но есть 50% скидка для студентов.

Во всех трёх тестируется один и тот же дистрибутив Debian 10.6.0 amd64, просто потому что у меня был уже скачан iso образ, с практически одинаковыми настройками при установке (немного отличается разбиение диска), в качестве среды рабочего стола везде выбрал Xfce. В качестве бенчмарков взял первые попавшиеся для linux sysbench (cpu, memory и io тесты) и indigo benchmark (cpu тест). Для всех виртуалок во всех системах были выставлены одинаковые настройки: 2GB оперативной памяти, 2 ядра процессора, 64MB видеопамяти. Тесты так же проведены в нативной macOS (для сравнения).

Всё тестировалось на MacBook Pro 13" 2017-го года с Core i5 на 2.3 GHz, ось macOS Big Sur Beta (20A5364e).

Отдельное замечание по поводу VirtualBox. После установки надо в настройках безопасности подтвердить, что мы доверяем расширениям ядра от Oracle, о чём установщик, в отличие от установщиков Fusion и Parallels, не предупреждает, а лишь говорит, что нужно перезагрузиться. После перезагрузки для этого подтверждения уже надо будет переустанавливать заново VirtualBox, потому что запрос на подтверждение пропадёт из настроек macOS (почему Apple не хранит их в отдельном разделе настроек безопасности?), но мне и это не помогло, и VirtualBox заработал лишь после сброса настроек SIP (sudo csrutil clear). В общем, потребовалось немного танцев с бубном.

Итак, вот результаты (полный вывод бенчмарков тут):

VMware Fusion Parallels Desktop Oracle VirtualBox macOS (host)
sysbench CPU (1 поток), events per second 1.2K 1.2K 1.2K 3607.9K
sysbench CPU (2 потока), events per second 2.4K 2.4K 2.4K 6111.5K
sysbench RAM, MiB/sec transferred 5411.45 4287.38 4863.09 2658.28
sysbench I/O, written MiB/sec 948.55 89.13 33.77 429.31
Indigo Bedroom, CPU, M samples/s 0.202 0.202 0.202 0.313
Indigo Supercar, CPU, M samples/s 0.514 0.502 0.496 0.787


Как видно, в синтетических тестах CPU наши виртуалки сильно отстают от оригинальной системы (что логично), но между собой отличаются незначительно. Интересно, что во всех трёх виртуальных машинах тест памяти значительно опережает тесты в macOS. С чем это связано гадать не буду, надеюсь не с разницей в linux и macOS версиях бенчмарка. Если кто-то знает или предполагает причину, объясните мне, пожалуйста, в комментариях. Точно так же любопытно, как Fusion обогнал macOS с тестами диска, но тут я ещё потестирую, так как скорость записи хорошо влияет на производительность, и тесты диска хорошо подвержены случайным факторам.

Что касается субъективного впечатления, parallels и vmware мне показались шустрее. К тому же при установке системы в VirtualBox курсор в один прекрасный момент завис и мне пришлось доустанавливать всё с клавиатуры, после ребута виртуалки пофиксилось. А в VMware система у меня начинает подтормаживать при включённой поддержке 3D ускорения, почему так я, опять же, не знаю.

В заключение скажу, что тесты, конечно, не точные и далеко не полные. Я взял первые попавшиеся бенчмарки и не тестировал, например, GPU. Тесты делал я в первую очередь для себя за один вечер, но решил поделиться с общественностью, думаю есть те, кому пригодится. Если кто-то проведёт более полные и качественные тесты производительности буду рад. Я же лично остановлюсь на Fusion Player, потому что он бесплатный, удобный для меня, к тому же у меня уже был приятный опыт использования VMWare Workstation на windows и не очень приятный с VirtualBox там же.
Подробнее..

Убираем старые проблемы защиты крупных и малых сетей

24.11.2020 12:18:29 | Автор: admin


Черепаха особое построение римских легионеров.


До сих пор существует практика разделять подход к безопасности для небольших компаний и для крупного бизнеса. С одной стороны, вроде бы логика в этом прослеживается. Якобы для штаб-квартиры в столице требуется высокий уровень безопасности, а для небольшого филиала уровень попроще и пониже.


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


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


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


Zyxel знает про эти проблемы и предлагает комплексный подход для решения.


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


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


Ниже мы разберём, как это выглядит на практике. Забегая вперёд, стоит сказать, что речь пойдёт о недавно поступившей в продажу платформе USG FLEX.


Почему облачные технологии так важны?


Коллективная защита


Количество угроз постоянно растёт. Если ограничить выбор только в пользу обычных локальных средств, то потребуется всё больше ресурсов. И всё больше усилий будет уходить на постоянную модернизацию, постоянный контроль ресурсов, попытки снизить нагрузку на шлюз безопасности и так далее.


Борьба средств безопасности против сетевых угроз это уже не классический сценарий самый твёрдый наконечник против самого крепкого щита, сейчас ситуация стала значительно интересней. Представьте себе поле боя, когда количество копий, мечей, секир и других атакующих объектов несётся на вас со всех сторон, а у вас в руках один щит. Тут самое время попросить помощи у соратников. Если сложить щиты в плотную конструкцию, можно отразить гораздо больше атак с самых разных сторон, нежели в одиночку.


В 5 веке до нашей эры римская армия, до этого копирующая боевое построение греков фалангу, кардинальна сменила тактику в пользу манипульного построения пехотинцев (см. рисунок выше). Современники в то время крутили пальцем у виска, предрекая Риму скорое поражение. Однако смелый ход оправдал себя и позволил Риму уверенно побеждать на протяжении следующих 600 лет.


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


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

Что делается для повышения защиты?


В облако Zyxel Security Cloud поступают данные об угрозах из различных источников. В свою очередь межсетевые экраны серии USG FLEX используют облачную базу данных в режиме Cloud Query Express, которая включает миллиарды сигнатур.


То есть это не скромная локальная антивирусная база, целиком загружаемая из Интернет, а гораздо более мощная конструкция. Если говорить о скорости взаимодействия, то функция Cloud Query проверяет хэш-код подозрительного файла за несколько секунд и при этом точно диагностирует угрозу.


Если говорить о количественных показателях, то при работе в режиме Cloud Query Express были получены результаты дополнительного прироста производительности UTM до 500%. При этом уровень потребления локальных вычислительных ресурсов не растёт, а снижается за счёт использования облачных мощностей, высвобождая локальные ресурсы для других задач.


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


В целом, за счёт использование более современной платформы рост производительности межсетевого экрана достигает 125%.


Откуда поступают данные о вредоносных элементах?


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


Отдельно стоит отметить хорошую контекстную фильтрацию, а также специальный фильтр CTIRU (Counter-Terrorism Internet Referral Unit) для ограничения доступа к экстремистской информации. В последнее время, к сожалению, эта функция становится необходимой.


Давайте попробуем галопом-по-европам пробежаться по основным ступенькам защиты, предоставляемым USG FLEX.


Среди функций безопасности стоит выделить такие возможности, как:


  • антивирусная защита;
  • антиспам;
  • фильтрация URL и IDP для отражения атак извне;
  • Патруль приложений;
  • контентная фильтрация (вместе с Патрулем приложений эти функции блокируют доступ пользователей к посторонним приложениям и web-сайтам);
  • инспекция SSL с поддержкой TLS 1.3. (для анализа защищённого трафика).

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


Аналитические отчёты и углублённый анализ угроз


В принципе, у Zyxel всегда было неплохо со статистикой и построение отчётов. В USG FLEX это поучило дальнейшее развитие. Графические диаграммы по статистике угроз, сводка статистики по трафику выводятся на главной консоли межсетевых экранов, это позволяет быстро понять, что происходит в сети.


Сервис SecuReporter предоставляет детальный анализ угроз, что даёт возможность вовремя проследить изменения в сети и вовремя избежать неприятностей.


Когда все события отображаются на одной централизованной консоли это удобно. Управлять разными клиентами и устройствами теперь стало проще.


Не только безопасность


Как говорится, безопасность безопасностью, но ещё и работать надо. Что предлагается для организации работы в USG FLEX?


Много разных VPN


Серия USG FLEX поддерживает VPN на основе IPsec, L2TP, SSL. Это позволяет не только организовать межсайтовое взаимодействие по защищённым каналам (полезно для крупных организаций с большим числом филиалов), но и наладить безопасный доступ к корпоративной сети удалённым работникам или малым полевым офисам.


Немаловажную роль играют возможности удалённой настройки. Удалённый доступ с нулевой конфигурацией упрощает настройку. В том числе, даже если нет ИТ-поддержки на местах всё равно можно настроить подключение по VPN к удалённому офису.


Для чего нужна расширенная подписка?


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


Расширенная подписка добавляет лицензии на Unified Threat Management для поддержки функций:


  • Web Filtering Блокирование доступа к опасным и подозрительным web-сайтам;
  • IPS (IDP) проверка пакетов на наличие вредоносного кода;
  • Application Patrol анализ поведения приложений, их классификация ранжированный подход в использовании сетевых ресурсов;
  • Anti-Malware проверка файлов и выявление опасных сюрпризов с использованием облачных мощностей;
  • Email Security поиск и блокировка спама, а также защита от фишинга посредством электронной почты;
  • SecuReporter расширенный анализ в области безопасности, построение подробных отчётов.

Пакет сервисов Hospitality


USG FLEX создан не только для обеспечения прямых функций безопасности, но и для контроля сети. Набор функций для Hospitality позволяет автоматически обнаруживать и производить конфигурацию точек доступа. Также в пакет входят: управление хот-спотами (биллинг), управление точками доступа с поддержкой Wi-Fi 6, различные функции управления доступом к сети и увеличение максимально допустимого числа авторизованных пользователей.


Проще говоря, Hospitality Pack служит именно для расширения возможностей контроллера беспроводной сети (сам по себе встроенный контроллер уже может автоматически обнаруживать и производить конфигурацию до 8 точек доступа, в том числе Wi-Fi 6). Hospitality Pack позволяет увеличить количество точек и авторизованных пользователей до максимума, добавить возможности биллинга и поддержки принтеров печати квитанций.


Есть отдельные бессрочные лицензии на увеличение количества точек (+ 2/4/8/64 AP), на увеличение количества авторизованных пользователей (+100/300) и на функцию биллинга с поддержкой принтеров.


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

Панель инструментов серии USG FLEX предоставляет удобную для пользователя сводку трафика и визуальную статистику угроз.


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


Миграция без усилий и проблем


Если используются лицензии серии USG в этом случае USG FLEX обеспечивает бесшовную миграцию лицензий. Можно обновить систему защиты до новой комплектной лицензии UTM 6-в-1 более полной версии защиты. Подробнее об этом можно посмотреть в видео.


Подробнее об устройствах USG FLEX


Прежде чем приступим к описанию, остановимся на ключевых моментах.


Как было сказано выше, очень важно обеспечить единообразие среди используемого оборудования. Зачастую системные администраторы сталкиваются с проблемой, когда слабое оборудование уровня СМБ или даже SOHO (начальный уровень) требуется увязать с мощными решениями уровня Enterprise.


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


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


Совет. Чтобы получить устройство на тест, нужно прислать запрос по адресу: Sales_rusc@zyxel.eu

Если говорить про USG Flex, то данная линейка на данный момент содержит целых 5 устройств:


  • USG FLEX 100 и версию с точкой доступа Wi-Fi USG FLEX 100W.
  • USG FLEX 200;
  • USG FLEX 500;
  • USG FLEX 700.

Важно отметить, что все они поддерживают одинаковые протоколы VPN, функцию контроллера точек доступа (8 точек со стандартной лицензией при покупке), антивирус, антиспам, IDP (обнаружение и предотвращение вторжений), Патруль приложений, контентную фильтрацию, возможность подключить SecuReporter Premium по подписке.


Ниже мы остановимся подробно на каждой модели USG FLEX.


Описание USG FLEX 100


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


Устройство мало потребляет, питание осуществляется от внешнего адаптера на 2A, 12V постоянного тока.


Имеет 4 порта LAN/DMZ, 1 порт WAN, 1 порт SFP.


Также присутствует порт USB, через который можно подключит USB-модем для создания резервного канала.



Рисунок 1. Внешний вид USG FLEX 100.



Несколько слов о USG FLEX 100W


В принципе, модель USG FLEX 100W отличается от модели USG FLEX 100 только встроенным модулем Wi-Fi.


Характеристики Wi-Fi:


  • Соответствие стандартам 802.11 a/b/g/n/ac
  • Частота радиосвязи 2.4 / 5 ГГц
  • Количество радио модулей 2
  • Количество SSID 8
  • Количество антенн 3 съёмные антенны
  • Усиление антенны 2 дБи @ 2.4 ГГц
  • Скорость передачи данных 802.11n: до 450 Мбит/сек, 802.11ac: до 1300 Мбит/сек.


Рисунок 2. Внешний вид USG FLEX 100W.


Как уже было сказано выше, основные отличия лежат в количественных показателях:


  • Пропускная способность SPI (Мбит/сёк) 900
  • Пропускная способность VPN (Мбит/сёк) 270
  • Пропускная способность IDP(Мбит/сёк) 540
  • Пропускная способность AV (Мбит/сёк) 360
  • Пропускная способность UTM (AV и IDP) 360
  • Максимум одновременных TCP сессий 300,000
  • Максимум одновременных туннелей IPSec 40
  • Максимум одновременных туннелей SSL 30

Описание USG FLEX 200


А это уже вариант немного мощнее.


Имеет 4 порта LAN/DMZ, 1 порт SFP, но есть отличие 2 два порта WAN (вместо одного в USG FLEX 100), что позволяет организовать отказоустойчивую схему с двумя проводными провайдерами.


Для питания нужен уже блок на 2,5A 12V постоянного тока.



Рисунок 3. Внешний вид USG FLEX 200.


По производительности и пропускной способности показатели также выше:


  • Пропускная способность SPI (Мбит/сёк) 1,800
  • Пропускная способность VPN (Мбит/сёк) 450
  • Пропускная способность IDP(Мбит/сёк) 1,100
  • Пропускная способность AV (Мбит/сёк) 570
  • Пропускная способность UTM (AV и IDP) 550
  • Максимум одновременных TCP сессий 600,000
  • Максимум одновременных туннелей IPSec 100
  • Максимум одновременных туннелей SSL 60
  • VLAN интерфейсы 16

Если сравнивать с более мощными моделями (о которых пойдет речь ниже), USG FLEX 200 всё-таки создан для сравнительно небольших нагрузок и кабинетного размещения. Об этом говорит и небольшой корпус, и внешний блок питания.


Но, тем не менее, USG FLEX 200 способен обеспечить хорошую поддержку сети в плане безопасности и организации работы сетевых сервисов, таких как управление точками доступа.


Описание USG FLEX 500


Это ещё более мощное устройство, имеет 7 конфигурируемых портов. Также присутствует 1 порт SFP и 2 порта USB 3.0


Примечание. Конфигурируемые порты позволяют избежать привязки к конкретному сценарию использования: нужно 1 порт WAN и 6 LAN нет проблем, нужно организовать отказоустойчивую схему на 3 проводных канала можно легко переназначить 3 WAN и 4 LAN порта.

Видно, что это универсальное устройство для решения широкого спектра задач.


Для питания нужен ещё более мощный блок 4.17А, 12V постоянного тока.


Для охлаждения внутри корпуса используется вентилятор, поэтому может создаваться шум. USG FLEX 500 скорее устройство для серверной или для кроссовой комнаты, нежели для компактного размещения в офисном пространстве.



Рисунок 4. Внешний вид USG FLEX 500.


Разумеется, по сравнению с предыдущими моделями, производительность отличается в большую сторону:


  • Пропускная способность SPI (Мбит/сёк) 2,300
  • Пропускная способность VPN (Мбит/сёк) 810
  • Пропускная способность IDP(Мбит/сёк) 1,500
  • Пропускная способность AV (Мбит/сёк) 800
  • Пропускная способность UTM (AV и IDP) 800
  • Максимум одновременных TCP сессий 1,000,000
  • Максимум одновременных туннелей IPSec 300
  • Максимум одновременных туннелей SSL 150
  • VLAN интерфейсы 64

Описание USG FLEX 700


Это устройство появилось позже всех, его можно назвать флагманом линейки. Имеет целых 12 конфигурируемых портов, 2 порта SFP, 2 порта USB 3.0


Питание производится из стандартной сети переменного тока 100-240V, 50/60Hz, ~2.5А.


Для охлаждения применяется встроенный вентилятор.


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



Рисунок 5. Внешний вид USG FLEX 700.


Имеет самую высокую производительность из всех USG FLEX на данный момент


  • Пропускная способность SPI (Мбит/сёк) 5,400
  • Пропускная способность VPN (Мбит/сёк) 1,100
  • Пропускная способность IDP(Мбит/сёк) 2,000
  • Пропускная способность AV (Мбит/сёк) 1,450
  • Пропускная способность UTM (AV и IDP) 1,350
  • Максимум одновременных TCP сессий 1,600,000
  • Максимум одновременных туннелей IPSec 500
  • Максимум одновременных туннелей SSL 150
  • VLAN интерфейсы 128


Подведём небольшой итог:


  • И большие и малые сети требуют заботы о безопасности.
  • Облачные решение упрощают построение и обслуживание защищённой сети.
  • Новая линейка Zyxel USG FLEX как раз для этого и создавалась.

Полезные ссылки


  1. Telegram chat Zyxel
  2. Форум по оборудованию Zyxel
  3. Много полезного видео на канале Youtube
  4. Преимущества USG FLEX
  5. Полезная статья в КБ о USG FLEX
  6. Видео: Перенос лицензий с устройств USG на устройства USG FLEX Series
  7. Описание USG-FLEX-100
  8. Описание USG-FLEX-100W
  9. Описание USG-FLEX-200
  10. Описание USG-FLEX-500
  11. Описание USG-FLEX-700
Подробнее..

Черная пятница 2020 (скидки на хостинг)

27.11.2020 04:16:45 | Автор: admin
Скидки к Черной пятнице уже никого не удивляют. Навязчивые предложения купить слона слышны из каждого утюга, так что я не был уверен в том, что хочу добавлять к этим голосам свой, но когда мне уже показалось, что я завязал, они снова меня туда затащили.



Некоторые хостеры интересовались, не забыл ли я добавить их в сборник со скидками, а пользователи в телеграме спрашивали, не будет ли повторения акций к семилетию Поиск VPS (нет), так что хотя бы на Черную пятницу и Киберпонедельник было решено сделать небольшой пост.

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

Host4biz скидка 90% на виртуальный хостинг, 50% на виртуальные серверы
Hyper Host скидка 90% на виртуальный хостинг, 30% на виртуальные серверы
A2 Hosting скидка до 78% на виртуальный хостинг, VPS/VDS и выделенные серверы
ITL DC скидка 70% на виртуальный хостинг, 55% на виртуальные и выделенные серверы
Bacloud скидка 66% на виртуальные и выделенные серверы
HostSailor скидка до 65% на виртуальный хостинг и VPS/VDS, до 20% на выделенные серверы, 20% на реселлинг
HOSTKEY скидка до 60% на выделенные серверы
Dominant Telecom скидка 60% на виртуальный хостинг
ISPLevel скидка 55% на виртуальные и выделенные серверы
OVH скидка до 50% на виртуальные серверы, до 40% на виртуальный хостинг, до 37% на выделенные серверы
EuroHoster скидка 50% на виртуальные серверы, 20% на выделенные серверы
ProfitServer скидка 50% на виртуальные серверы
Veesp скидка 50% на виртуальные и выделенные серверы
FOXCLOUD скидка 50% на виртуальные серверы
Inferno Solutions скидка 50% на виртуальные серверы, 20% на выделенные серверы
Interserver скидка 50% на виртуальный хостинг
King Servers скидка 40% на виртуальные серверы, специальная цена на выделенные серверы
FriendHosting скидка 30% на виртуальный хостинг и VPS/VDS
G-Core Labs скидка 30% на выделенные серверы, 40% на услуги CDN, Streaming Platform, DDoS Protection, Storage и Cloud
PlanetaHost скидка 25% на выделенные серверы
OneProvider скидка до 25% на выделенные серверы
WebHOST1 скидка 20% на хостинг и виртуальные серверы, возврат 20% средств, потраченных на дополнительные услуги, специальная цена на выделенный сервер
FASTVPS скидка 20% на виртуальные серверы, 10% на выделенные серверы, 30% на сертификаты SSL
KeyWeb скидка 20% на виртуальные серверы
PQ.Hosting скидка 15% на все виртуальные серверы
Majordomo скидка 20% на настройку рекламы и аудит сайта
RedDock 3 месяца в подарок к оплате на год, 2-й месяц бесплатно на виртуальный сервер
RackNerd специальные цены на виртуальный хостинг, виртуальные и выделенные серверы
BlueVPS удвоение параметров виртуального сервера
Миран бесплатная лицензия Windows Server для каждого выделенного сервера
Hostens специальная цена на виртуальный хостинг


Срок действия: до 30 ноября 2020 года включительно
Скидка 90% на виртуальный хостинг, 50% на виртуальные серверы по промокоду BLACKFRIDAY2020.
Подробнее
  • при заказе любого тарифа услуги Хостинг сайтов с промокодом BLACKFRIDAY2020 на период от 1 года скидка на первые 6 месяцев пользования услугой составляет 90%;
  • при заказе любого тарифа услуги Хостинг WordPress с промокодом BLACKFRIDAY2020 на период от 1 года скидка на первые 6 месяцев пользования услугой составляет 90%;
  • при заказе любого тарифа услуги сервер Linux VPS с промокодом BLACKFRIDAY2020 на период от 6 месяцев скидка составляет 50% на первые 3 месяца;
  • скидки объединяются с постоянными скидками, указанными на сайте;
  • акционным промокодом можно воспользоваться только один раз;
  • предложение действительно только для новых заказов.

Условия акции


Срок действия: 27 ноября 2020 года
Скидка 90% на виртуальный хостинг, 30% на виртуальные серверы.
Подробнее
Промокод не требуется, скидка применяется к новым заказам при оплате на 1 или 3 месяца.
Условия акции


Срок действия: undefined
Cкидка до 78% на виртуальный хостинг, реселлинг, VPS/VDS и выделенные серверы
Подробнее
  • виртуальный хостинг от $1.99 в месяц;
  • реселлинг от $14.99 в месяц;
  • хостинг для WordPress от $9.99 в месяц;
  • Виртуальные серверы от $19.99 в месяц;
  • выделенные серверы от $129.3 в месяц.

Условия акции


Срок действия: до 03 декабря 2020 года
Скидка 70% на виртуальный хостинг, 55% на виртуальные и выделенные серверы по промокоду BLACKFRIDAY2020.
Подробнее
  • скидка 55% на HDD-сервер с процессором Intel Xeon E3-1230v3-v6, 32Gb ECC RAM и парой дисков 2TB;
  • скидка 70% на все хостинговые планы при оплате на 6 или 12 месяцев;
  • скидка 55% на все планы SSD VDS. Для минимального плана SSD VDS 1G скидка доступна при заказе на 3, 6 или 12 месяцев, для остальных планов для любого периода;
  • количество активаций кода ограничено, добавленные в корзину и не активированные в течение акционного периода заказы будут аннулированы по окончании акции.

Условия акции


Срок действия: до 30 ноября 2020 года
Скидка 66% на виртуальные серверы по промокоду VPS66 и выделенные серверы E5v4D210D по промокоду DS66.
Подробнее
Скидка на виртуальные серверы действует на тарифы Linux KVM и Windows KVM.
Условия акции


Срок действия: undefined
Cкидка до 65% на виртуальный хостинг и VPS/VDS, до 20% на выделенные серверы, 20% на реселлинг.
Подробнее
  • скидка 65% при заказе хостинга или виртуального сервера на год по промокоду BF65%ANN;
  • скидка 50% при заказе хостинга или виртуального сервера на месяц по промокоду BF50%MON;
  • скидка 30% при заказе виртуального сервера KVM Storage на год по промокоду BLACKF2020;
  • скидка 20% при заказе выделенного сервера в Румынии на год по промокоду BF20RO;
  • скидка 10% при заказе выделенного сервера Fujitsu в Нидерландах на год по промокоду BF10%NL;
  • скидка 20% при заказе реселлинга на год по промокоду BLACKFRI20.

Условия акции


Срок действия: до 29 ноября 2020 года
Скидка до 60% на выделенные серверы, кешбэк в размере 20% от суммы платежа, безлимитный трафик для выделенных серверов.
Подробнее
  • скидка 60% на первый месяц и 20% на остальное время аренды выделенных серверов 2x Intel Xeon E5-2680v2 в Нидерландах;
  • скидка 30% на второй месяц аренды выделенных серверов с GPU в Нидерландах;
  • скидка 20% при аренде выделенного сервера с 2 процессорами в России на срок 6 месяцев и более;
  • при заказе более чем на 500 евро кешбек в размере 20% от суммы на баланс аккаунта;
  • безлимитный трафик на скорости 1 Гбит/с при аренде двухпроцессорных серверов в США или Нидерландах с AMD, Intel Xeon Silver или 2x Intel Xeon E5-2680v2.

Условия акции


Срок действия: undefined
Скидка 60% на первый платеж за виртуальный хостинг
Подробнее
Максимальный период заказа 3 года.
Условия акции


Срок действия: до 30 ноября 2020 года включительно
Скидка 55% на виртуальные серверы во всех локациях и выделенные серверы Intel Xeon E3-1230v3-v6 / 32GB RAM / 2x2TB HDD по промокоду BF2020.
Подробнее
Виртуальный сервер Level 1 можно получить со скидкой при оплате от 3 месяцев. Для остальных тарифов минимальный период заказа составляет 1 месяц.
Условия акции


Срок действия: до 04 декабря 2020 года
Скидка до 50% на виртуальные серверы, до 40% на виртуальный хостинг, до 37% на выделенные серверы, 150 на баланс облачных услуг по промокоду BF2020, специальные цены на регистрацию доменных имен, скидки на SMS и Email рассылку.
Подробнее
Скидки зависят от периода заказа.
Условия акции


Срок действия: до 27 ноября 2020 года
Скидка 50% на виртуальные серверы в Нидерландах, Болгарии и США по промокоду BlackFriday2020, выделенные серверы в Нидерландах со скидкой 20% по промокоду BlackFriday2020Dedic.
Подробнее
  • VPS 1 vCPU / 1 GB RAM / 10 GB SSD / 100 Mbit/s 2.50
  • VPS 2 vCPU / 2 GB RAM / 20 GB SSD / 100 Mbit/s 6.00
  • VPS 1 vCPU / 2 GB RAM / 200 GB SSD / 100 Mbit/s 7.50
  • Dedic Intel Core i3 2100 2 x 3.10 GHz / 4 GB RAM / 120 GB SSD / 100 Mbit/s 19.60
  • Dedic Intel Xeon E-2234 4 x 3.60 GHz (4.80 GHz Turbo) / 8 GB RAM ECC DDR4 / 120 GB SSD / 100 Mbit/s 42.48
  • Dedic Intel Xeon E3-1270v6 4 x 3.80 GHz / 8 GB RAM / 240 GB Enterprise SSD / 100 Mbit/s 49.52

Условия акции


Срок действия: до 29 ноября 2020 года включительно
Скидка 50% на виртуальные серверы в Москве (DataPro) по промокоду BFMOSCOW.
Подробнее


Срок действия: до 03 декабря 2020 года
Скидка 50% на первый платеж за виртуальные и выделенные серверы для новых клиентов по промокоду 50BF2020.
Подробнее


Срок действия: до 01 декабря 2020 года
Скидка 50% на первый платеж за любой Linux VPS по промокоду $ale-Black-Cyber. При оплате за 3, 6 или 12 месяцев применяется дополнительная скидка от 10% до 25%.
Подробнее
Предложение доступно только для новых клиентов. Скидка распространяется на панель управления ISPManager. Предложение ограничено. Скидки за период оплаты применяются последовательно.
Условия акции


Срок действия: до 30 ноября 2020 года
Скидка 50% на все тарифы VPS по промокоду BF2020VPS, скидка 20% на серверы RU / NL3 по промокоду BF2020DED.
Подробнее
  • скидка 50% на все тарифы VPS по промокоду BF2020VPS, скидка 20% на серверы RU / NL3 по промокоду BF2020DED;
  • при пополнении баланса на сумму от $10 до $2000 по запросу в поддержку начисляется бонус в размере 20% от суммы.

Условия акции


Срок действия: до 02 декабря 2020 года
Постоянная скидка 50% на виртуальный хостинг.
Подробнее
Безлимитный хостинг за $2.5 в месяц.
Условия акции


Срок действия: до 29 ноября 2020 года
Скидка 40% на виртуальные серверы, специальная цена на выделенные серверы в Нидерландах
Подробнее
  • на виртуальные серверы с ценой от $10 в месяц при оформлении нового заказа на 3 месяца и более предоставляется скидка 40%, действующая на первый период оплаты; для активации следует обратиться в техническую поддержку;
  • специальная цена цена на выделенные серверы в Нидерландах (2xIntel E5-2620v4, 2xIntel E5-2630v3, 2xIntel Xeon Gold 5118, 2xIntel E5-2680v4) сохраняется при продлении, 14 дней использования предоставляются в подарок, количество ограничено.

Условия акции


Срок действия: до 07 декабря 2020 года
Для новых заказов на первый период оплаты предоставляется скидка 30% по промокоду BF2020.
Подробнее
  • для новых заказов на первый период оплаты, но не более 6 месяцев, предоставляется скидка 30% по промокоду BF2020;
  • для заказов, сделанных до начала акции, при продлении на 12 месяцев дополнительно к скидке 10% и скидке по программе лояльности по запросу в финансовый отдел предоставляется 1 месяц в подарок.

Условия акции


Срок действия: до 06 декабря 2020 года включительно
Cкидка 30% на выделенные серверы при заказе на 1 год, скидка 40% или бонус в размере $100 для новых клиентов на услуги CDN, Streaming Platform, DDoS Protection, Storage и Cloud.
Подробнее
  • для новых клиентов скидка 40% на услуги CDN, Streaming Platform, DDoS Protection, Storage и Cloud по промокоду BF2020 (указывается при регистрации, скидка применяется в конце биллингового периода);
  • для новых клиентов бонус $100 при заказе CDN, Streaming Platform, DDoS Protection, Storage и Cloud с промокодом 100USD (указывается при регистрации, бонус будет начислен в конце биллингового периода);
  • для существующих клиентов скидка 40% на подключение дополнительного сервиса CDN, Streaming Platform, DDoS Protection, Storage и Cloud по промокоду NEWSERVICE;
  • скидка 30% на любой выделенный сервер при заказе на 1 год по промокоду DEDICDOLLAR, DEDICEURO или DEDICRUBLE в зависимости от выбранной для расчетов валюты.

Условия акции


Срок действия: undefined
Скидка 25% на выделенные серверы с процессорами Intel Xeon E3-1220v3, E3-1240v3 и E5-2620.
Подробнее
Цены действительны при продлении сервера, на каждый выделенный сервер бесплатно предоставляется панель ISPmanager на все время пользования услугой.
Условия акции


Срок действия: до 04 декабря 2020 года
Скидка до 25% на выделенные серверы в различных локациях.
Подробнее
  • скидка до 25% на все конфигурации выделенных серверов в Дюссельдорфе (Германия);
  • скидка до 20% на все конфигурации выделенных серверов в Сиэтле (США);
  • специальные цены на выделенные серверы в США, Франции, Нидерландах, России и Сингапуре.

Условия акции


Срок действия: до 27 ноября 2020 года включительно
Скидка 20% на хостинг и виртуальные серверы по промокоду bf20, возврат 20% средств, потраченных на дополнительные услуги, специальная цена на выделенный сервер.
Подробнее
  • скидка 20% на хостинг и виртуальные серверы;
  • возврат 20% от средств, потраченных на дополнительные услуги (администрирование сайта или сервера, защита от жалоб), производится по запросу в поддержку;
  • при заказе выделенного сервера (2х Intel Xeon 5645 / 32 GB RAM / 2x 960 GB SSD) действует специальная цена 8000 рублей в месяц, количество серверов ограничено;
  • скидка по промокоду и кешбэк не суммируются.

Условия акции


Срок действия: до 03 декабря 2020 года
Скидка 20% на виртуальные серверы, 10% на выделенные серверы, 30% на сертификаты SSL по промокоду FASTVPS-BF20.
Подробнее
  • скидка 20% на виртуальные серверы (кроме тарифов VF и SAS);
  • скидка 10% на физические выделенные серверы;
  • скидка 30% на сертификаты SSL;
  • бесплатно предоставляется панель управления сервером, техническая поддержка, перенос 10 сайтов общим объемом до 60 GB при наличии технической возможности;
  • предложения не суммируются с другими акциями и действуют только на первый платеж.

Условия акции


Срок действия: до 15 декабря 2020 года
Скидка 20% на виртуальные серверы CloudVM S3-S10 по промокоду BlackFriday2020.
Подробнее
Скидка предоставляется однократно и действует на первый платеж на любой доступный период заказа. Действует только на новые заказы.
Условия акции


Срок действия: 27 ноября 2020 года
Скидка 15% на все виртуальные серверы по промокоду blackfriday.
Подробнее


Срок действия: до 29 ноября 2020 года включительно
Скидка 20% на настройку рекламы и аудит сайта.
Подробнее
Скидка 20% при заказе настройки контекстной рекламы или рекламы в социальных сетях, SEO-аудита или аудита качества сайта.
Условия акции


Срок действия: до 29 ноября 2020 года
3 месяца в подарок к оплате на год, 2-й месяц бесплатно на виртуальный сервер
Подробнее
  • три месяца в подарок при приобретении любого из тарифов Bitrix или RED.Site на год;
  • второй месяц бесплатно при приобретении виртуального сервера RED.Site-2 или RED.Site-3.

Условия акции


Срок действия: undefined
Специальные цены на виртуальный хостинг, виртуальные и выделенные серверы.
Подробнее
  • Linux VPS от $8.89 в год;
  • Windows VPS от $60 в год;
  • Выделенные серверы от $89 в месяц;
  • Виртуальный хостинг от $8.5 в год;
  • Реселлинг от $24.99 в год.

Условия акции


Срок действия: с 18:00 (GMT+2) 27 ноября до 18:00 (GMT+2) 28 ноября 2020 года
Удвоение параметров виртуального сервера.
Подробнее
Удвоение параметров любого оплаченного виртуального сервера. Детальная информация доступна в Live-чате на сайте или системе тикетов.
Условия акции


Срок действия: до 31 декабря 2020 года
Бесплатная лицензия Windows Server для каждого заказанного выделенного сервера.
Подробнее
При аренде любого выделенного сервера бесплатно предоставляется лицензия Windows Server Standard 2012, 2016 или 2019 до конца 2021 года. Промокод: WINDOWSZA0 или WIN0.
Условия акции


Срок действия: до 00:00 (GMT+2) 01 декабря 2020 года
Виртуальный хостинг и бесплатный домен за $9 в год.
Подробнее
Виртуальный хостинг (10 GB HDD, 10 сайтов, 10 баз данных, cPanel) и домен в зоне .online, .store, .website, .tech или .site за $9 в год.
Условия акции
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru