Продолжение поста «Обратный случай: когда украинские клиенты используют российский SaaS сервис с серверами в России»
К сожалению, был забанен длительное время. Потому не смог продолжить пост. А завершилось все хорошо. Я думал, что все это безобразие закончится быстро. Когда понял, что ошибался, поставил клиента перед фактом, что без оплаты с первого числа отключаю сервер. Клиент из Украины с готовностью согласился продолжать сотрудничество на прежних условиях. Оплата идет через биткоин. Работаем как и до СВО. Единственное отличие - что перед выставкой счета я читаю новости - не слишком ли сильно город, в котором живет и работает мой клиент, бомбили сегодня ночью. Если сильно, то я выставляю счет на следующий день. Чисто, так сказать, по человечески.
Так что те пропагандисты, которые утверждают, что русские и украинцы никогда не помирятся, нагло врут! Уже помирились! В этом году меня поздравила с днем рождением сестра из Украины. А я ее. Правда, сообщениями. Чтоб не провоцировать.
Фирма наша российско-украинская все так же продолжает работать. Про политику, само собой, не говорим. Название фирмы не скажу, ибо СБУ не дремлет. А наши украинские коллеги нам здорово помогают обходить санкции.
Где-то читал легенду, что когда-то в Азии разразилась война. И шла она долго и людям надоела. И люди попросили тибетских монахов ее остановить. Монастыри тогда отправили 100 монахов, и те своими проповедями остановили войну. Так вот, найти бы ту сотню черных магов, которые стравили братские народы, и разбудить бы их окончательно. Тогда бы и настал мир между нашими народами.
Мира всем!
Как я спасаю данные каждый день (или не спасаю): часть вторая
Wubba Lubba Dub-Dub, пикабушники, я вернулся из отпуска (но об этом отдельно).
Наконец закрылось окно бэкапа и теперь можем снова подушнить. В предыдущем своём посте я кратко рассказал о будничных пертурбациях инженера резервного копирования. В этой же части я расскажу о подходах нашей команды.
Как говорится: хорошая статья — залог успеха, заключённые согласятся, а мы поехали.
Давным-давно это был самый обычный кабинет под номером 611. В нём мирно и активно работали сначала продажники, после них продакт-менеджеры и не знали они бед. Мир шатко держался в равновесии, пока однажды народ инженеров не развязал войну и не отнял эту территорию. Хотя по некоторым данным кабинет освободился в ковидные времена, ну да ладно, в нём всё равно никто не сидел в период "самоизоляции".
С тех самых пор как в него перебрался я, бывший инженер службы эксплуатации центров обработки данных (ЦОД) и нынешний инженер систем резервного копирования, кабинет превратился во всеми почитаемый «Душный уголок», который открыт избранным и закрыт… неизбранным ¯\_(ツ)_/¯.
В нашем кабинете воистину собрались настоящие душнилы, но в то же время профессионалы своего дела. Я и коллеги совместными стараниями поддерживаем всю IT-инфраструктуру наших Заказчиков, будь то серверы, СХД, LAN/SAN, виртуализация, облачные сервисы, ОС, прикладные службы и СРК, само разумеется.
Так вот продолжим тему СРК. Со времён ещё когда-то тогдашнего ведения своей деятельности иностранных вендоров на территории РФ наша команда бэкаперов занималась поддержкой таких решений как Veritas NetBackup и Backup Exec, EMC NetWorker, CommVault и IBM TSM (последними двумя занималась только часть моих коллег, т.к. проектов по ним было не так много). В Veeam мы, конечно, тоже можем, но кейсов по ним на нас прилетало не так много.
Сейчас, после начала специального крестового похода, когда иностранные вендоры ушли, мы продолжаем пользоваться нашей богатой экспертизой и поддерживать эти продукты у тех, у кого они ещё остались, но также наш портфель пополнился свежими решениями: Кибер Бэкап, РуБэкап и парочка китайских Aishu AnyBackup и VinChin. Open source решения мы не поддерживаем, т.к. профита в такой поддержке нет. К тому же комьюнити само по себе хорошо справляется с настройкой и траблшутингом.
Чем бэкапим мы разобрались. А вот на что — тут уже зоопарк поразношёрстнее. Тут всё работает по классике: "горячие" данные крутятся на SSD-стораджах, а вот "холодные" и "архивные" уже у нас на HDD и ленточных носителях. В самых редких случаях используются и VTL (Virtual Tape Library). Я уже понял, что вам интересно узнать обо всём чуточку подробнее, поэтому в дальнейшем планирую выпустить статьи по терминологиям и компонентам СРК. Пишите в комментариях о чём вам хотелось бы узнать.
В комментариях к прошлому посту упомянули про такое золотое правило как «3-2-1». Оно гласит следующее: храни не менее 3 копий — 2 на нескольких разных хранилищах и 1 на удалённом. Это самое короткое пояснение, но не самое подробное. На самом деле у нас есть своё правило, которое звучит так: «Храни копии так, чтобы ты всегда смог из них восстановиться».
Можно бесконечно много проектировать инфраструктуру так, чтобы у тебя был переизбыток, но это не всегда оправдано, т.к. бэкапы не ограничиваются 3 копиями. Обычно это длинные цепочки полных и промежуточных копий, которые хранятся месяцами и важно осознанно подходить к тому, что тебе нужно хранить, а что нет. И тебе обязательно нужно учитывать как оно хранится: в каком виде, как получить доступ к этим копиям, а как получить доступ, если доступа не будет. И это не правило резервного копирования — это серьёзная задача к построению отказоустойчивости и катастрофоустойчивости всей инфраструктуры.
Вот здесь мы подходим к тому, что связность всегда должна быть при любой ситуации. Грамотный выбор сетевого оборудования, интерфейсов, компонентов и среды передачи данных позволяет распределять нагрузку на сеть, масштабировать её, защищать информацию и обеспечивать доступность даже в критических условиях. Это отдельная очень большая тема.
Сейчас важно лишь понимать, что в нашем случае есть несколько типов сетей: вычислительная сеть (LAN/WLAN), через которую проходит связь компонентов и взаимодействие протоколов, обеспечивающих мониторинг, управление, да в принципе любое привычное взаимодействие компьютеров, серверов и периферии; и сеть хранения данных (SAN), через которую осуществляется выделенная высокоскоростная передача данных между системами и устройствами хранения.
Сразу скажу, что резервные копии могут передаваться и так, и так. В идеале, резервное копирование эффективнее выполнять напрямую по SAN, т.к. даже при равной пропускной способности каналов она обеспечивает более надёжное и быстрое взаимодействие дисковых подсистем, не забивая при этом вычислительный канал связи. Но это не всегда возможно (например, с облачным хранилищем).
В нашей работе мы придерживаемся традиционных планов РК (резервного копирования), в которых любое взаимодействие с данными продуктивных систем происходит в наименее загруженные часы. Как правило, это время с 20:00 до 08:00 в будние дни и выходные дни целиком, если это компания с базовым 5-дневным графиком. Однако для каждой компании могут быть свои исключения вплоть до определённой информационной системы.
Например, резервные копии некоторых чрезмерно больших кластеров баз данных выгоднее по производительности создавать с клона стэндбай ноды, который был создан на уровне СХД. Для чего? — Чтобы не создавать излишнюю нагрузку на стэндбай, т.к. это приведёт к задержке синхронизации активной ноды со стэндбай и это будет очень нехорошо для прикладной системы (кто угадает о какой СУБД идёт речь?). К счастью, такие ситуации бывают редки и во всех остальных случаях кластеры мы бэкапим просто с его стэндбай ноды.
Ну и давайте затронем тогда уже тему того, как мы проверяем резервные копии. Конечно, такие проверки возможны лишь там, где это позволяет функционал выбранного ПО СРК, но как правило всё сводится к тому, что резервная копия проверяется на целостность с помощью контрольных сумм, восстановления где-нибудь в виртуальной песочнице, либо фактического штатного восстановления.
Копия прошла проверку? — Хорошо, однако это всё равно не гарантирует нам того, что в нужный момент мы сможем из неё восстановиться. Почему? — Потому что в нашей работе на всё нужно смотреть пессимистично. Чем больше ты найдёшь для себя причин «почему это сломается» — тем больше ты проработаешь моментов, которые увеличат шансы на успех. Поэтому мы всегда в первую очередь обращаем внимание не на то, сколько копий мы храним, а как мы это делаем.
Работать инженером СРК не только очень весело... но и не очень. СРК — это в принципе система, которая внедряется с надеждой на то, что ею никогда не придётся воспользоваться (или хотя бы не так часто). И это не потому, что она такая страшная — нет. Просто в первую очередь СРК служит прекрасным спасением при человеческом факторе и вмешательстве. Потеря данных систем по причине неполадок железа, как правило, должна пресекаться на уровне самого железа.
Поэтому несмотря на все мемы — к бэкаперам обращаются чаще всего тогда, когда либо кто-то что-то нажал и всё пропало (в случае с плохим мануал-терапевтом мы тут вам не поможем), либо когда всё сломалось настолько, что спасут только бэкапы.
Увидимся в новых сериях!
Как я пошел в IT
Привет всем. Мне 36 в этом году, решил сменить вид деятельности. Записался на бесплатный семинар по АйТи. Послушал, и сказал: - Пошли вы нахуй со своим Айти . Вернулся на стройку. Дома строить полезнее для общества.
Как я вошел в ИТ?
Как, как - 31 год назад поступил в ТУСУР, теперь выйти из ИТ не могу!
Поиграем в бизнесменов?
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Доступно об АйТи: Почему полоса прогресса ходит неравномерно
Ну вот и я подключусь к волне постов и расскажу кое-что на этот счёт.
Кто виноват и что делать? И кому на Руси жить хорошо?
Опять для Лиги лени поставлю телегу впереди лошади.
Сначала отвечу на третий вопрос — хорошо начинающим программистам, ведь современные библиотеки позволили очень маленькой кровью, например, загружать сайт, а потом извлекать из него информацию. Чтобы загрузить страницу, можно просто исполнить программу cURL, которая есть в Windows 10 начиная с патча 1803, а в *nix — была с давних пор.
Виновато усложняющееся устройство компьютера, как аппаратное, так и программное. Например, между винчестером — зеркалом, вращающимся со скоростью болгарки — и файлом — цепочкой байтов с именем — есть аппаратный дисковый кэш, программный дисковый кэш, драйвер диска, драйвер файловой системы и файловые функции ОС.
А что делать — не знаю. Я смирился, тем более психологи показывают, что прогрессу достаточно идти вперёд, и пользователь всё поймёт.
И оглавление, снова для Лиги лени.
Иногда ей надо ходить неравномерно.
Загрузка — сложный процесс.
Обратная связь — затратная операция.
Иногда программа не может вызвать обратную связь.
Иногда обратную связь вызвать архитектурно сложно.
Пристёгивайтесь, поехали!
Иногда ей надо ходить неравномерно
Пример: торрент-клиент
Что происходит, когда мы скачиваем файл по протоколу распределённой закачки? (Считаем, что интернет хороший.)
Клиент обращается к трекеру (или бестрекерной сети), чтобы найти тех, у кого этот файл есть. И заодно сам объявляет трекеру, что мы этот файл хотим. Прогресс стоит.
Потихоньку сползаются раздающие — поползли по сети первые блоки. Прогресс разгоняется.
Скорость дошла до предела, предлагаемого нашим провайдером или найденными раздающими — прогресс идёт равномерно.
Файл скачан почти весь, докачиваются последние блоки. Часть раздающих отключаем, скорость падает — прогресс замирает на 99%.
Скачан самый слоупочный блок — всё, 100%!
И в этом случае есть вполне измеримый показатель прогресса — скачанный процент. Ему и не надо идти равномерно. Но: программа по каким-то собственным формулам может вычислять, когда закачка кончится, и тут уже всё как в дальнейших примерах.
Загрузка — сложный процесс
Пример: любая игра или инсталлятор
Пример с торрент-клиентом я уже привёл. Посмотрим, что творится в любой игре.
Загрузка из интернета — зависит как от пинга к серверу, так и от скорости этого самого интернета.
Доступ к файлам — на SSD почти мгновенный, на механическом диске — ощутимую долю секунды.
Линейное чтение файла — зависит от скорости диска.
Распаковка файла (почти всегда игра сжата каким-нибудь ZIP’ом) — тут уже действует процессор.
Передача распакованного в видеопамять — подключается видеошина.
Будь у нас компьютер с полностью стандартным железом, на манер ZX Spectrum, всё было бы понятно. Но ведь IBM стали стандартом именно потому, что имели множество разных процессоров, дисков и другой аппаратуры, от дешманских до high-end. А интернет-соединение вообще никак и нигде не стандартизировано.
Один из разработчиков сказал: «вот в этой точке мы перемещаем прогресс на 20%», что это значит? Он сидел с часиками и смотрел на отладочный вывод, и понял, что вот этот шаг отнимает примерно 20% времени. Примерно: на другой машине это может быть 10 или 30%. У разработчика — любого — есть один перекос: они пользуются мощными машинами, и потому отмеренные 20%, скорее всего, будут относиться именно к мощному компу.
А это уже личный опыт. Загрузку игры на Java ME я делил на 10–20 примерно одинаковых шажков. Это могла быть загрузка графики, тригонометрических таблиц, спрайтовых таблиц и много чего ещё. Показывается заставка разработчика/распространителя — игра грузится, но прогресса пока нет. Показывается заставка игры — прикидываем процент загрузки, и делаем одно из трёх.
Игра под заведомо быстрый мобильник (Nokia Series 40, Sony Ericsson серий K и Z) — нет индикатора. В таких портах на заставке даже нет места под индикатор.
Игра прикидывает, что загрузка закончится за те минимум 2,5 секунды, что отданы на заставку — тоже нет индикатора.
Или всё-таки рисует индикатор, но он идёт от 0 до 100%, даже если за время первой заставки игра ухитрилась проскочить 4 шажка из 12. Если оставшиеся восемь проскочила со скоростью звука — всё равно заставка висит минимум 2,5 секунды, с прогрессом 100%.
Обратная связь по прогрессу — затратная операция
Когда я пришёл в ту контору, писавшую игры для мобильников, их игры могли грузиться минуту и более. На Nokia Series 60, которая тогда была базовым портом! Перестав дёргать прогресс без нужды, мы ту же S60 отнесли к «условно быстрым» — какие-то телефоны ухитрялись всё загружать за пять-шесть секунд заставок, какие-то чуть дольше.
Давайте о том, как можно обеспечить обратную связь на ПК под управлением Windows (о других ОС не знаю).
Самый технически простой. Ничего не делать, только грузить, иногда на короткие моменты передавая управление главному окну. Грузит и рисует полностью последовательно: пока окно перерисовывается, загрузка не идёт. Игра выглядит «застрявшей», не реагирует на управление, ОС может даже сказать: программа не отвечает, хотите дождаться?
Одно ядро процессора полностью занято интерфейсом — программа уже реагирует на клавиатуру и мышь. А второе, загрузчик, также время от времени приостанавливается, пока главный не скажет: «У меня есть свободное время» — и не обновит информацию о прогрессе. По времени мало чем лучше первого: грузит и рисует почти последовательно.
Этот способ самый сложный, но и самый быстрый. Загрузчик кладёт информацию в «почтовый ящик». Главное ядро время от времени этот ящик трясёт — и выводит его содержимое. Если в ящике всего одна цифра, это очень просто — 4 или 8 байт, в зависимости от архитектуры процессора, перейдут от процессора к процессору неиспорченными. Но с более сложной отладочной информацией надо неплохо так заморочиться, чтобы этой порчи не было — и чтобы не было того, что грузит и рисует последовательно (см. 2).
💽 грузить, 🖌️ рисовать, ⚙️ отрабатывать сообщения Windows, ⬛ обмен данными, 🚬🎋 простаивать
Иногда программа не может вызвать обратную связь
Пример: копирование в Windows на флэшку
Просто не может, и точка. Из чужих библиотек — каких-нибудь закачек, распаковок или математики — обратную связь вызвать очень сложно (придётся их дописывать), из системных вызовов — вообще нельзя.
Чем отличается копирование на винчестер (нет защиты от небезопасного извлечения) от копирования на флэшку (таковая есть)? Последним шагом, закрытием файла! Если копирование на винчестер, пользователь уже получил управление, но Windows ещё несколько секунд трещит, сбрасывая данные на диск — на флэшке сброс идёт сразу при закрытии, ведь надо защитить флэшку от небезопасного извлечения! Минуту, без всякой обратной связи.
Иногда обратную связь вызвать архитектурно сложно
Пример: последние шаги большинства инсталляций или расчётов
Вот поэтому прогресс часто зависает на 100%. Система бывает просто не приспособлена, чтобы запускать эти последние шаги на другом процессоре. Удаление временных файлов, перерисовка пользовательского интерфейса, дополнительные мини-расчёты, которые выполняются с каждым кликом мышью…
Эти шаги можно загнать под прогресс, но это требует непропорционального объёма программистской работы.