Поражает не тот факт, что разработчики плюют на нас десятилетие (их дело, пусть себе плюют), а тот, что вот это вот недоразумение другие странные люди суют в топовые дистры и потом прыгают с переподвыподвертом выше своих и наших голов, чтобы этот террор пользователей (не побоюсь этого слова) поддерживать и дальше. Странно то, что на фоне такого количества хейта гном ещё не засунули куда подальше (на пыльные полки бумажных распечаток инструкций LFS, например) и там же навсегда о нём благополучно забыли. Пусть себе народ-гномовод развлекается где-нибудь очень далеко и не портит пользователям настроение.
Недавно мой батя себе приобрёл новый ноут (на старом появилась полоска через весь экран). И он посчитал, что уже достаточно опытный пользователь Linux, чтобы самостоятельно снести винду, шедшую в комплекте, и поставить привычный дистрибутив, но немного ошибся и скачал не тот iso, вместо искомого xubuntu.
Я очень долго смеялся и потешался, когда он после завершения установки не смог выключить компьютер. Он битый час сидел, тыкал мышкой в интерфейс гнома в попытках разобраться и найти кнопку выключения! Ему это так и не удалось! Потом он всё же сдался и позвонил мне. Я потратил на это значительно меньше времени, даже не пытаясь идти его путём и разбираться в этом... — просто порекомендовал прижать и держать кнопку выключения до тех пор, пока сама материнка не вырубит питание. Очевидно, что следующее включение компа было уже исключительно с целью установки OS с человеко-понятным интерфейсом, а батя так до сих пор и остался в недоумении от неожиданного опыта — знакомства с глубинами маразма дизайнерской мысли :-D
Нет, не пересчитывает сначала, продолжает считать с того места в файле, до которого были хеши рассчитаны в прошлом проходе, просто продолжает. Но только если метаданные фала не менялись.
обход каталога однопоточный или можно как-то распараллелить
Пока однопоточный. Есть запрос фич по разным методам распараллеливания.
Нам, рядовым постсоветчикам, это сложно понять, но это часть культуры америкосов. Они никогда не оспаривают мнение других и никогда не выступают с критикой, особенно в профессиональной и технологической среде. Поэтому слова Вы прочли правильно, но смысл как раз в том, что это бунт против решения.
Ну да, ну да… И в статье, конечно, ни слова о реальных причинах, начавшихся в феврале 22, из-за которых рынок теперь «не умирает». Только достаточно глянуть на представленный график, чтобы всё стало понятно.
Сейчас да, я полностью соглашусь. Тогда, когда я только пробовал свою первую Raspberry Pi, задача стояла не в том ключе, чтобы разориться на покупку nvme, а попробовать вообще подойдёт малинка для тогдашних моих нужд или нет. Возможно да, это бы решило проблему UBOOT и расширило бы выбор OS, но сейчас меня итак устраивает и без лишних трат. Малинка прекрасно работает как backup-платформа, на которой можно даже что-то запустить с минимумом энергозатрат.
проделано многонедельные работы, но зачем?
Ради результата. Сейчас у меня два ёмких диска на двух сторонах и я ничем не ограничен в своих желаниях хранить любой объём интересующих меня данных; синхронизация с проверкой и полная уверенность в идентичности данных; прямой доступ к данным через обе железки — к обеим точкам я могу за считанные секунды подключиться через интернет и добраться до любого файла.
Несомненно, HDD не конкуренты NVME дискам. И вообще магнитная технология заведомо обречена на увядание. Однако обещания Samsung выпустить четыре года назад NVME диски пользовательского уровня ёмкостью 100Tb пока так и остаются обещаниями. Учитывая ≅6 кратную разницу в стоимости хранения одного мегабайта продолжаем жить с HDD и жать светлого будущего.
забыть о многонедельных попытках восстановления
NVME точно так же НЕ гарантируют 100% сохранности и доступности данных как и HDD. Рано или поздно, но и с любыми solid state возникнут проблемы. Даже солидных брендов. Технология увы, не совершенна. Это не просто слова, это неоднократный личный опыт.
Перед ответом я тщательно подумал над Вашим так точно заданным вопросом! И да, совершенно верно, была бы опция прерывания, — не было бы статьи, не было бы и моего личного опыта в борьбе с несовершенством цифровой реальности.
Но! На самом деле я рад этому опыту! Есть такой термин, часто используемый в разработке: Test Oracle — тестовый Оракул. Это некая независимая сущность, призываемая для проверки результата.
Ещё тогда, когда я уже начал использовать rsync для рабочих нужд, не до конца понимая всех нюансов его работы, я интуитивно чувствовал, что использовании единственного инструмента может таить угрозу. И потом, внезапно потеряв кусок важного дампа БД в DRC банка я в этом убедился воочию. Пришлось вникать в нюансы и строить процедуры периодического восстановления из бэкапов на архитектуре DRC. Это было чертовски сложно и долго, но действительно гарантировало восстановление работы на резервных ресурсах в случае проблем с основным DC. Это и был тот самый Оракул, который проверял результат.
precizer в данном случае тоже является оракулом, связанным с основным инструментом синхронизации, только через данные. Простым, но от этого не менее эффективным.
Угрозы могут идти не только от rsync. ПО или железо. Развалившийся RAID, проблемы с бэдблоками на дисках в более простых решениях, сбои на сетевом уровне, баги в ПО: как внутри rsync, так и в любом другом. Всё это несёт реальную угрозу рассинхронизации.
После наступания на «грабли» я теперь осознаю важность тестового Оракула. Не precizer, так какой-то другой инструмент. Поэтому все мои текущие и будущие решения в обязательном порядке будут построены на этом принципе.
От души благодарю. Значит не зря старался! Думаю, в будущем больше никто так не будет писать не потому, что весь мой айтишный опыт — продукт того самого диалапа, времён абсолютной свободы фидо, субкультуры udaff и padonkaf, а потому, что все ленятся и получается юридически выверенный, стерильный текст, выс…ый AI. Ну хорошо, может не ленятся, но экономят личный невозобновляемый ресурс — время.
Меня когда то сильно впечатлил стиль текстов Andy Weir: добрый, умный, сложный и с циничным юмором. Наверно, это теперь неосознанно отражается в том, к чему сам стремлюсь.
Сейчас вспоминаю и с удивлением осознаю, что раньше можно было писать обо всём и на любую тему, и за это тебе ничего не было (кроме злобных модераторов, которые могли кенсельнуть пост, конечно! :)
А теперь каждый телефон о тебе докладывает куда нужно и там где нужно знают о тебе больше, чем ты сам.
Хоть сейчас трава за моим окном и зеленее, чем была раньше за моим другим окном в прошлой жизни, но всё равно, поразительные и удивительные были времена! :-D
syncthing
Моё первое знакомство с этим решением состоялось несколько лет назад, когда я пытался отправить родственнику через полпланеты огромный архив со словарями Goldendict и их индексацией. Тогда это казалось восхитительной идеей: и тебе торрент-протокол, и шифрование, и контрольные суммы и докачка. По-факту промучались неделю с нулевым результатом и пришлось искать альтернативные пути. Это при том что между нами нет ни каких DPI или какой-либо другой дряни, которая могла бы потенциально помешать передаче.
Потом была ещё одна попытка завернуть трафик syncthing в туннель или любой VPN и тоже безуспешно — эксперименты остановились на стадии исследования. Цель полностью недостижима архитектурно, несмотря на заверения нескольких источников в обратном.
Идеи заложены правильные, но тратить время на это кривое поделие я больше не хочу. Может быть, когда-нибудь, напишут на хорошем языке программирования что-то в таком же стиле, но действительно работающее. Но это будет уже не syncthing.
rsync не идеален, но он работает. Он полностью надёжен и предсказуем. Не вижу смысла менять что-то архитектурно, что уже проверено годами. Улучшить — да, можно. И статья именно об этом.
Мой опыт ограничивается только замерами на паре вариантов несильно старых x86_64 CPU, поэтому да, возможно мои выводы были поспешны. Спасибо за точку зрения!
Моё личное наблюдение — sha512sum работает быстрее, чем sha256sum
К предложенной схеме с find/rs/sort/diff есть несколько вопросов:
Если мне хочется проигнорировать директорию с сериалами, которые я вообще не бэкапирую и которые занимают половину диска? А если список для игнорирования состоит из трёх десятков пунктов? Лично в моём случае так и есть для rsync — передаю их параметрами в скрипте резервирования.
Что если мне нужно продолжить с прерванного места?
Что в плане обновлений через месяц, например, чтобы актуализировать все изменения после бэкапа? Перерасчёт с нуля всех 25Tb?
Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах. Думал, что ничего сложного нет.
там суммы считаются/проверяются во все потоки
Каким алгоритмом рассчитываются суммы? Это алгоритм с поддержкой многопоточности или под многопоточностью подразумевается обращение к диску в несколько потоков для чтения файлов? Просто интересуюсь.
Хотел бы как автор статьи написать ответ. Как мне показалось, Ваш комментарий был именно адресный. С одной стороны Вы во всём правы, ничего такого в DevOps неправильного нет. Всё разумно, логично, взаимосвязано и абсолютно последовательно соблюдаются все причинно следственные связи. Но…
Лень идти читать, но думаю той же посторе и мускулу уже не 5 и не 10 лет.
Если бы только ограничивалось постгрёй и мускелем. Ан нет… Это вообще не из сферы DevOps. Там этого не достаточно. Им подавай Aurora, DynamoDB, DocumentDB, Keyspaces, Neptune, Timestream LiveAnalytics, Redshift, RDS (отдельный зоопарк), ElastiCache, MemoryDB, OpenSearch Service и это только стэк Amazon Web Services и только в сфере БД. Перечислить зоопарк остальных вендоров? Не? Хватит?
Не лень. Просто реально ни времени ни оперативы держать в голове весь этот бардак не хватает просто биологически. Слишком много информации и слишком ко́роток срок жизни этих технологий. Думаю через 10 лет даже половины из перечисленного списка либо не будет уже существовать вообще, либо они трансформируются во что-то совершенно другое.
такого нытья
Тут много раз в комментариях уже упоминался именно этот термин. И да, нельзя не согласиться с целесообразностью его использования. Статья действительно получилась уж сильно эмоциональной, очень “соль на рану” и по-живому. Потому что тогда рана действительно была и она здорово припекала. Новые поиски работы, новые сомнения, моральные страдания и то чувство, когда ощущаешь себя ничтожеством среди мэтров своего дела на очередном собесе, на котором тебя носом тычут в новые технологии и недоумевают как такие “элементарные” вещи можно не знать.
Не знаю их и больше знать не хочу! Вот честно!
Сколько прошло с тех времён? Год? Полтора? Только что прокрутил до даты создания статьи. Нда… Потрясно… Два года уже прошло! За два года эмоции поутихли, но лично моё мнение сформировалось надёжно и наверно уже навсегда. Сейчас можно честно признавать, что в статье больше эмоций чем объективной оценки средней температуры по палате. За что статью не раз критиковали (обосновано) в комментариях. Которые сами нередко были предельно эмоциональны… Ну да ладно… Мы все люди а не роботы, у нас есть чувства, эмоции и не только умом и холодным расчётом формируется наша жизнь и профессиональные предпочтения.
Пару лет назад я сделал выбор и надо сказать что очень удачный. Сейчас меня устраивает буквально всё. AI убрал из программирования ту тупую рутину печатания, которая многих вводила в уныние. Лично я просто в восторге от процесса кодинга с агентами! Чувствую себя художником, а не “машинисткой” печатной машинки, вынужденной к тому же угадывать синтаксис разыменования указателей. В моей жизни теперь много Си и на работе и как хобби и я ну ни капли не жалею о таком радикальном развороте моей профессиональной карьеры, к которому я упорно шёл сквозь годы. Я расту и совершенствуюсь в этом ЯП. Да, он сложный и даже после долгих лет работы открываешь для себя много нового снова и снова. Особенно, когда есть AI у которого можно получить разъяснения, а не так как раньше: ждёшь ответа неделями, но так и не получаешь. Потому что профи либо заняты, либо лень, а остальные 99,99999% прочитавших вопрос просто не знают на него ответа.
Чего в моей жизни больше нет или что улучшилось за это время:
Теперь я сплю крепко даже тогда, когда условно “дежурный” на телефоне (как разработчик). Я далеко не первая линия обороны между конечными потребителями и продуктом который пишу и за всё это время ни разу меня не побеспокоили именно по поводу проблем с ним связанным.
Нет тех тревог, которые были из-за уровня ответственности за продакшн и проблем связанных с многослойностью технологий, когда на каждом этапе что-то может пойти не так и всё — конец покою и кроме тебя, девопса и виноватых-то больше найти не получится!
Я отвечаю только за ОДНУ(!) софтину которую пишу, а не за тот зоопарк технологий наговнокоженный абы-как и кем попало под громкими брендами типа Amazon или Oracle. Если отвалилась из сети пачка серверов с моей софтиной, то кто виноват? Правильно — кто угодно, но не я. Моя софтина как выключатель: либо работает, либо нет — тут всё просто. А кто отвечает за всё остальное? Маршрутизация, внутренняя сеть, железо, виртуализация, кластеризация, контейнеризация, операционки, обновления, ядра, драйверы? Правильно: команда тех самых девопс-инженеров, мечтающая выспаться хоть разочек. Мне остаётся только утром вместо новостей с чашкой кофе читать сводки по сбоям (так… по-диагонали пробежаться, чтобы понять затрагивает это мой сектор или нет).
Все это развивается, но…
Вот всё на первый взгляд в DevOps логично и правильно:
Виртуализация — это совершенно логичный шаг в попытке рационально уплотнить использование софта на очень быстро эволюционирующем железе.
Контейнеризация — такой же логичный шаг в направлении развития деплоймента, миграции, отказоустойчивости, изоляции и версионирования.
IaC — абсолютно разумная технология в попытке навести порядок и управлять сотнями и тысячами единиц ресурсов.
Но всё это логично и правильно только на первый взгляд. По факту, все эти красивости состоят из стянутых кое-как и склеенных соплями в пучок сотен тысяч программно-аппаратных компонентов разных производителей и у разных поставщиков услуг (библиотеки, комплексные программы, чипы, прошивки, операционки, ядра, драйверы устройств) в которых есть миллионы своих мелких или крупные багов и скрытых проблем. И DevOps не только не контролирует ни одну из этих миллионов скрытых проблем, он даже не подозревает об их существовании, потому что инженер управляет сущностями на совершенно другом уровне абстракции.
Приведу простой пример: терраформ работал-работал и вдруг перестали выставлять проперти на s3 бакет. Один долбаный бакет! Накатываем - откатывается. Каждый этап — полчаса. Бьёмся день. Где баг? В конфиге этого бакета, который не менялся уже как год? Через что-то другое задели, потому что настройки пропертей шарятся среди десятков других сториджей? В день делается с десяток изменений командой из нескольких человек. Кто поломал? Откат гитом всей конфигурации на сутки назад: тот же результат — не можем накатить вообще никаких изменений из-за этого одного бакета. Выставляем проперти вручную — всё работает. Неделя в попытках разобраться спускается в унитаз и под занавес — проблема исчезает сама собой. В анонсах AWS - ни слова ни о баге ни о его ремонте. Неделя отравленного времени, настроения, скандалов и бессонницы, обвинения от кого угодно в некомпетентности и даже саботаже на всех уровнях руководства. Всё это — банальный график ежедневной работы рядового DevOps инженера. Надо оно лично мне? О нет! Уверен — не хочу во всё это окунаться больше ни разу, даже если мне при этом будут подавать ключи (как в том анекдоте).
Одна из тех причин почему выбор пал именно на Си, это самодостаточность. Программе на Си не нужны виртуальные движки как Java, PHP или NodeJS с их версионностью, багами, деприкейтами и legacy, не нужны кеширующие прекомпиляторы и другие костыли. Не нужны зависимости, зависящие от зависимых зависимостей в которых постоянно находят чужие интружены (сорян, каламбур сам по себе напрашивался, навеянный dependencies в NodeJS и проблемами с ними связанными).
В Си тоже широко используются библиотеки, но это не разрушает самодостаточности. Чем выше самодостаточность — тем меньше потенциальных точек отказа, тем выше стабильность, предсказуемость и контролируемость. То, чего мне не хватало в DevOps — ощущения стабильности, предсказуемости и контроля, я в гораздо большей степени нашёл в Си-разработке.
На работе у меня код, который писался в течение 35 лет и насчитывает около 170 000 строк. Сложный, стабильный и с нулевым покрытием юнит-тестами (тогда TDD был не в фаворе) К тому же, код изначально писался и развивался под AIX (была такая OS, а может и есть до сих пор) которая, кстати, big-endian с нативной кодировкой EBCDIC вместо привычной нам ASCII. И что? И ничего! За пару месяцев весь этот код без особых последствий силами двух очень хорошо разбирающихся программистов портировали на Linux x86_64 который уже little-endian. Теперь софт продолжает успешно трудиться на фундаментально другом железе, другой операционке и собранный абсолютно другим компилятором.
В чём тут принципиальное отличие от философии DevOps? Нет лишних слоёв абстракций! Всё максимально просто, поэтому надёжно как до сих пор работающий лом, доставшийся в наследство от прадедушки вместе с сарайчиком, в котором стоят пластиковые китайские грабли, гнущиеся в нужных и, главное, в ненужных местах на все 180 градусов, как современные облачные технологии, прогибающиеся под прихоти в самые замысловатые позы.
DevOps как набор идей логичен. Но конкретная работа DevOps-инженера во многих компаниях превращается в жизнь на стыке чужих абстракций, чужих багов, чужих API, чужих бизнес-решений и твоей персональной ответственности. Лично мне этот тип нагрузки оказался разрушителен.
Кто-то вообще пишет веб на Си??
Пишет! :-D
Даже фреймворки есть, чтобы не приходилось мудрить на примитивном уровне с printf(“%s”,"<html "); и даже их несколько. Прекрасно себе живут и пользуются популярностью, потому что софт на их базе потребляет в 10-20 раз меньше ресурсов по сравнению аналогичными решениями на других ЯП. Там где под Java web-приложение нужно 20 серверов под такую же логику программе на Си потребуется только два. Не всегда, не везде, не бесплатно по трудозатратам, но можно и это совершенно реально!
И бизнесу хорошо и нам есть что намазать на бутерброд.
Ну, у вас как был Linux, так и остаётся
У меня две домашние машины с Linux Gentoo. Два ядра из считающихся абсолютно стабильными веток. Между ними 3 месяца разницы и несколько минорных номеров. Одно ядро вообще беспроблемное — всё работает просто идеально. На второй машине обновил на более свежее и начались проблемы — через рандомное время крэшится всё что связано с иксами и сеансами пользователя. Подозреваю видеоподсистему, но надо сидеть разбираться. Пока просто откатил на то стабильное, трёхмесячной давности и всё опять в порядке.
К чему это я… Linux это такая же программа как всё остальное. И она может быть одним из сотен тысяч источников проблем для DevOps инженера. Не становитесь DevOps инженерами! И даже сисадминами не надо! :-)
…поддерживать работу сотен сервисов и сотен серверов…
Зачем это всё? Зачем только трудов и опасной ответственности? Слишком много рисков по сравнению с работой в сфере программирования! Не становитесь DevOps инженерами! :-D
Обнял. Всем желаю успехов от души! И DevOps, и простым пользователям.
Сделает! СДЕЛАЕТ! Окружение решает многое, если не всё! Сейчас обосную:
Предположим, Вы — бомж. У вас один уровень решаемых задач и проблем: где найти мусорник с едой и так, чтобы не побили «конкуренты»? Где переночевать при минус 15 (под мостом, как обычно не прокатит)? Как накатить чтобы забыться от всего этого и не думать о том, что будет завтра?
Теперь сравним с уровнем решаемых задач если Вы рядовой гражданин состоявшейся, социально-ориентированной страны без лишних потрясений: какая школа лучше ребёнку? Где комфортнее климат? Какое хобби лучше для души? Спорт? У какого работодателя интереснее задачи и выгоднее оплата? Какие интересные события можно организовать на завтра?
Есть такая мудрость, о которой сразу вспоминается в такие моменты: «Нельзя перейти море говна и не заляпаться, даже если ты в резиновых сапогах». Лучше сделать всё, чтобы держаться от такого «моря» подальше. Поэтому да, эмиграция — сделает жизнь лучше!
Сто́ит напомнить, что врать в завышать показатели — это часть культуры Китая. Из-за чего они вымирали миллионами во времена мао. Если верить их официальным заявлениям, так они и термояд уже давно победили, и в другие галактики летают на своих EmDrive. Поэтому понять что у них происходит с технологическими прорывами на самом деле очень и очень нелегко.
Хотя проблемы не столько с инновациями, а с их внедрением
Потому, что для внедрения любых инноваций нужны хорошо мотивированные и высококвалифицированные кадры, которые будут управляться стабильными бизнесами, владельцы которых уверены в своём "завтра", а так же в том, что их авторские права будут соблюдаться и защищатся международным правом. С учётом ТЕКУЩЕЙ обстановки, в пучину которой себя втянула страна, ничего из этого нет и не будет ещё десятилетиями.
История не выдуманная. Остальные домыслы и обвинения можете оставить при себе.
Поражает не тот факт, что разработчики плюют на нас десятилетие (их дело, пусть себе плюют), а тот, что вот это вот недоразумение другие странные люди суют в топовые дистры и потом прыгают с переподвыподвертом выше своих и наших голов, чтобы этот террор пользователей (не побоюсь этого слова) поддерживать и дальше. Странно то, что на фоне такого количества хейта гном ещё не засунули куда подальше (на пыльные полки бумажных распечаток инструкций LFS, например) и там же навсегда о нём благополучно забыли. Пусть себе народ-гномовод развлекается где-нибудь очень далеко и не портит пользователям настроение.
Недавно мой батя себе приобрёл новый ноут (на старом появилась полоска через весь экран). И он посчитал, что уже достаточно опытный пользователь Linux, чтобы самостоятельно снести винду, шедшую в комплекте, и поставить привычный дистрибутив, но немного ошибся и скачал не тот iso, вместо искомого xubuntu.
Я очень долго смеялся и потешался, когда он после завершения установки не смог выключить компьютер. Он битый час сидел, тыкал мышкой в интерфейс гнома в попытках разобраться и найти кнопку выключения! Ему это так и не удалось! Потом он всё же сдался и позвонил мне. Я потратил на это значительно меньше времени, даже не пытаясь идти его путём и разбираться в этом... — просто порекомендовал прижать и держать кнопку выключения до тех пор, пока сама материнка не вырубит питание. Очевидно, что следующее включение компа было уже исключительно с целью установки OS с человеко-понятным интерфейсом, а батя так до сих пор и остался в недоумении от неожиданного опыта — знакомства с глубинами
маразмадизайнерской мысли :-DЯ Вас услышал и Вы правы. Вам, наверняка, виднее. Не буду спорить.
Нет, не пересчитывает сначала, продолжает считать с того места в файле, до которого были хеши рассчитаны в прошлом проходе, просто продолжает. Но только если метаданные фала не менялись.
Пока однопоточный. Есть запрос фич по разным методам распараллеливания.
Ого! Кроссплатформенность, GUI! Я должен это увидеть! Выкладывайте код, не артачьтесь. Потом нейронками полирнуть, и будет по красоте!
Нам, рядовым постсоветчикам, это сложно понять, но это часть культуры америкосов. Они никогда не оспаривают мнение других и никогда не выступают с критикой, особенно в профессиональной и технологической среде. Поэтому слова Вы прочли правильно, но смысл как раз в том, что это бунт против решения.
ЦРУ собирает физические адреса разрабочтиков
Возобновление расчёта контрольной суммы разрешается только если полностью совпали реальные метаданные и записанные в БД: st_size, st_blocks, st_mtim.tv_sec, st_mtim.tv_nsec, не только mtime https://github.com/precizer/precizer/blob/ef72be800afa4321ce68553aa8fed1fa610fc05c/src/file_list.c#L498
Ну да, ну да… И в статье, конечно, ни слова о реальных причинах, начавшихся в феврале 22, из-за которых рынок теперь «не умирает». Только достаточно глянуть на представленный график, чтобы всё стало понятно.
Сейчас да, я полностью соглашусь. Тогда, когда я только пробовал свою первую Raspberry Pi, задача стояла не в том ключе, чтобы разориться на покупку nvme, а попробовать вообще подойдёт малинка для тогдашних моих нужд или нет. Возможно да, это бы решило проблему UBOOT и расширило бы выбор OS, но сейчас меня итак устраивает и без лишних трат. Малинка прекрасно работает как backup-платформа, на которой можно даже что-то запустить с минимумом энергозатрат.
Ради результата. Сейчас у меня два ёмких диска на двух сторонах и я ничем не ограничен в своих желаниях хранить любой объём интересующих меня данных; синхронизация с проверкой и полная уверенность в идентичности данных; прямой доступ к данным через обе железки — к обеим точкам я могу за считанные секунды подключиться через интернет и добраться до любого файла.
Несомненно, HDD не конкуренты NVME дискам. И вообще магнитная технология заведомо обречена на увядание. Однако обещания Samsung выпустить четыре года назад NVME диски пользовательского уровня ёмкостью 100Tb пока так и остаются обещаниями. Учитывая ≅6 кратную разницу в стоимости хранения одного мегабайта продолжаем жить с HDD и жать светлого будущего.
NVME точно так же НЕ гарантируют 100% сохранности и доступности данных как и HDD. Рано или поздно, но и с любыми solid state возникнут проблемы. Даже солидных брендов. Технология увы, не совершенна. Это не просто слова, это неоднократный личный опыт.
Перед ответом я тщательно подумал над Вашим так точно заданным вопросом! И да, совершенно верно, была бы опция прерывания, — не было бы статьи, не было бы и моего личного опыта в борьбе с несовершенством цифровой реальности.
Но! На самом деле я рад этому опыту! Есть такой термин, часто используемый в разработке: Test Oracle — тестовый Оракул. Это некая независимая сущность, призываемая для проверки результата.
Ещё тогда, когда я уже начал использовать rsync для рабочих нужд, не до конца понимая всех нюансов его работы, я интуитивно чувствовал, что использовании единственного инструмента может таить угрозу. И потом, внезапно потеряв кусок важного дампа БД в DRC банка я в этом убедился воочию. Пришлось вникать в нюансы и строить процедуры периодического восстановления из бэкапов на архитектуре DRC. Это было чертовски сложно и долго, но действительно гарантировало восстановление работы на резервных ресурсах в случае проблем с основным DC. Это и был тот самый Оракул, который проверял результат.
precizer в данном случае тоже является оракулом, связанным с основным инструментом синхронизации, только через данные. Простым, но от этого не менее эффективным.
Угрозы могут идти не только от rsync. ПО или железо. Развалившийся RAID, проблемы с бэдблоками на дисках в более простых решениях, сбои на сетевом уровне, баги в ПО: как внутри rsync, так и в любом другом. Всё это несёт реальную угрозу рассинхронизации.
После наступания на «грабли» я теперь осознаю важность тестового Оракула. Не precizer, так какой-то другой инструмент. Поэтому все мои текущие и будущие решения в обязательном порядке будут построены на этом принципе.
От души благодарю. Значит не зря старался! Думаю, в будущем больше никто так не будет писать не потому, что весь мой айтишный опыт — продукт того самого диалапа, времён абсолютной свободы фидо, субкультуры udaff и padonkaf, а потому, что все ленятся и получается юридически выверенный, стерильный текст, выс…ый AI. Ну хорошо, может не ленятся, но экономят личный невозобновляемый ресурс — время.
Меня когда то сильно впечатлил стиль текстов Andy Weir: добрый, умный, сложный и с циничным юмором. Наверно, это теперь неосознанно отражается в том, к чему сам стремлюсь.
Сейчас вспоминаю и с удивлением осознаю, что раньше можно было писать обо всём и на любую тему, и за это тебе ничего не было (кроме злобных модераторов, которые могли кенсельнуть пост, конечно! :)
А теперь каждый телефон о тебе докладывает куда нужно и там где нужно знают о тебе больше, чем ты сам.
Хоть сейчас трава за моим окном и зеленее, чем была раньше за моим другим окном в прошлой жизни, но всё равно, поразительные и удивительные были времена! :-D
Моё первое знакомство с этим решением состоялось несколько лет назад, когда я пытался отправить родственнику через полпланеты огромный архив со словарями Goldendict и их индексацией. Тогда это казалось восхитительной идеей: и тебе торрент-протокол, и шифрование, и контрольные суммы и докачка. По-факту промучались неделю с нулевым результатом и пришлось искать альтернативные пути. Это при том что между нами нет ни каких DPI или какой-либо другой дряни, которая могла бы потенциально помешать передаче.
Потом была ещё одна попытка завернуть трафик syncthing в туннель или любой VPN и тоже безуспешно — эксперименты остановились на стадии исследования. Цель полностью недостижима архитектурно, несмотря на заверения нескольких источников в обратном.
Идеи заложены правильные, но тратить время на это кривое поделие я больше не хочу. Может быть, когда-нибудь, напишут на хорошем языке программирования что-то в таком же стиле, но действительно работающее. Но это будет уже не syncthing.
rsync не идеален, но он работает. Он полностью надёжен и предсказуем. Не вижу смысла менять что-то архитектурно, что уже проверено годами. Улучшить — да, можно. И статья именно об этом.
Мой опыт ограничивается только замерами на паре вариантов несильно старых x86_64 CPU, поэтому да, возможно мои выводы были поспешны. Спасибо за точку зрения!
Моё личное наблюдение — sha512sum работает быстрее, чем sha256sum
К предложенной схеме с find/rs/sort/diff есть несколько вопросов:
Если мне хочется проигнорировать директорию с сериалами, которые я вообще не бэкапирую и которые занимают половину диска? А если список для игнорирования состоит из трёх десятков пунктов? Лично в моём случае так и есть для rsync — передаю их параметрами в скрипте резервирования.
Что если мне нужно продолжить с прерванного места?
Что в плане обновлений через месяц, например, чтобы актуализировать все изменения после бэкапа? Перерасчёт с нуля всех 25Tb?
Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах. Думал, что ничего сложного нет.
Каким алгоритмом рассчитываются суммы? Это алгоритм с поддержкой многопоточности или под многопоточностью подразумевается обращение к диску в несколько потоков для чтения файлов? Просто интересуюсь.
Toshiba MG06ACA10TE 10Tb был заменён на Seagate ST28000NM000C-3WM103 25TB Добавлю, пожалуй, эти данные в статью, чтобы расставить все точки над «ё».
Хм… Ноут! Это Вы ещё не меняли картридж в струйных принтерах HP… Вот это действительно задача, за решение которой нужно выдавать Нобелевскую! :-D
Хотел бы как автор статьи написать ответ. Как мне показалось, Ваш комментарий был именно адресный. С одной стороны Вы во всём правы, ничего такого в DevOps неправильного нет. Всё разумно, логично, взаимосвязано и абсолютно последовательно соблюдаются все причинно следственные связи. Но…
Если бы только ограничивалось постгрёй и мускелем. Ан нет… Это вообще не из сферы DevOps. Там этого не достаточно. Им подавай Aurora, DynamoDB, DocumentDB, Keyspaces, Neptune, Timestream LiveAnalytics, Redshift, RDS (отдельный зоопарк), ElastiCache, MemoryDB, OpenSearch Service и это только стэк Amazon Web Services и только в сфере БД. Перечислить зоопарк остальных вендоров? Не? Хватит?
Не лень. Просто реально ни времени ни оперативы держать в голове весь этот бардак не хватает просто биологически. Слишком много информации и слишком ко́роток срок жизни этих технологий. Думаю через 10 лет даже половины из перечисленного списка либо не будет уже существовать вообще, либо они трансформируются во что-то совершенно другое.
Тут много раз в комментариях уже упоминался именно этот термин. И да, нельзя не согласиться с целесообразностью его использования. Статья действительно получилась уж сильно эмоциональной, очень “соль на рану” и по-живому. Потому что тогда рана действительно была и она здорово припекала. Новые поиски работы, новые сомнения, моральные страдания и то чувство, когда ощущаешь себя ничтожеством среди мэтров своего дела на очередном собесе, на котором тебя носом тычут в новые технологии и недоумевают как такие “элементарные” вещи можно не знать.
Не знаю их и больше знать не хочу! Вот честно!
Сколько прошло с тех времён? Год? Полтора? Только что прокрутил до даты создания статьи. Нда… Потрясно… Два года уже прошло! За два года эмоции поутихли, но лично моё мнение сформировалось надёжно и наверно уже навсегда. Сейчас можно честно признавать, что в статье больше эмоций чем объективной оценки средней температуры по палате. За что статью не раз критиковали (обосновано) в комментариях. Которые сами нередко были предельно эмоциональны… Ну да ладно… Мы все люди а не роботы, у нас есть чувства, эмоции и не только умом и холодным расчётом формируется наша жизнь и профессиональные предпочтения.
Пару лет назад я сделал выбор и надо сказать что очень удачный. Сейчас меня устраивает буквально всё. AI убрал из программирования ту тупую рутину печатания, которая многих вводила в уныние. Лично я просто в восторге от процесса кодинга с агентами! Чувствую себя художником, а не “машинисткой” печатной машинки, вынужденной к тому же угадывать синтаксис разыменования указателей. В моей жизни теперь много Си и на работе и как хобби и я ну ни капли не жалею о таком радикальном развороте моей профессиональной карьеры, к которому я упорно шёл сквозь годы. Я расту и совершенствуюсь в этом ЯП. Да, он сложный и даже после долгих лет работы открываешь для себя много нового снова и снова. Особенно, когда есть AI у которого можно получить разъяснения, а не так как раньше: ждёшь ответа неделями, но так и не получаешь. Потому что профи либо заняты, либо лень, а остальные 99,99999% прочитавших вопрос просто не знают на него ответа.
Чего в моей жизни больше нет или что улучшилось за это время:
Теперь я сплю крепко даже тогда, когда условно “дежурный” на телефоне (как разработчик). Я далеко не первая линия обороны между конечными потребителями и продуктом который пишу и за всё это время ни разу меня не побеспокоили именно по поводу проблем с ним связанным.
Нет тех тревог, которые были из-за уровня ответственности за продакшн и проблем связанных с многослойностью технологий, когда на каждом этапе что-то может пойти не так и всё — конец покою и кроме тебя, девопса и виноватых-то больше найти не получится!
Я отвечаю только за ОДНУ(!) софтину которую пишу, а не за тот зоопарк технологий наговнокоженный абы-как и кем попало под громкими брендами типа Amazon или Oracle. Если отвалилась из сети пачка серверов с моей софтиной, то кто виноват? Правильно — кто угодно, но не я. Моя софтина как выключатель: либо работает, либо нет — тут всё просто. А кто отвечает за всё остальное? Маршрутизация, внутренняя сеть, железо, виртуализация, кластеризация, контейнеризация, операционки, обновления, ядра, драйверы? Правильно: команда тех самых девопс-инженеров, мечтающая выспаться хоть разочек. Мне остаётся только утром вместо новостей с чашкой кофе читать сводки по сбоям (так… по-диагонали пробежаться, чтобы понять затрагивает это мой сектор или нет).
Вот всё на первый взгляд в DevOps логично и правильно:
Виртуализация — это совершенно логичный шаг в попытке рационально уплотнить использование софта на очень быстро эволюционирующем железе.
Контейнеризация — такой же логичный шаг в направлении развития деплоймента, миграции, отказоустойчивости, изоляции и версионирования.
IaC — абсолютно разумная технология в попытке навести порядок и управлять сотнями и тысячами единиц ресурсов.
Но всё это логично и правильно только на первый взгляд. По факту, все эти красивости состоят из стянутых кое-как и склеенных соплями в пучок сотен тысяч программно-аппаратных компонентов разных производителей и у разных поставщиков услуг (библиотеки, комплексные программы, чипы, прошивки, операционки, ядра, драйверы устройств) в которых есть миллионы своих мелких или крупные багов и скрытых проблем. И DevOps не только не контролирует ни одну из этих миллионов скрытых проблем, он даже не подозревает об их существовании, потому что инженер управляет сущностями на совершенно другом уровне абстракции.
Приведу простой пример: терраформ работал-работал и вдруг перестали выставлять проперти на s3 бакет. Один долбаный бакет! Накатываем - откатывается. Каждый этап — полчаса. Бьёмся день. Где баг? В конфиге этого бакета, который не менялся уже как год? Через что-то другое задели, потому что настройки пропертей шарятся среди десятков других сториджей? В день делается с десяток изменений командой из нескольких человек. Кто поломал? Откат гитом всей конфигурации на сутки назад: тот же результат — не можем накатить вообще никаких изменений из-за этого одного бакета. Выставляем проперти вручную — всё работает. Неделя в попытках разобраться спускается в унитаз и под занавес — проблема исчезает сама собой. В анонсах AWS - ни слова ни о баге ни о его ремонте. Неделя отравленного времени, настроения, скандалов и бессонницы, обвинения от кого угодно в некомпетентности и даже саботаже на всех уровнях руководства. Всё это — банальный график ежедневной работы рядового DevOps инженера. Надо оно лично мне? О нет! Уверен — не хочу во всё это окунаться больше ни разу, даже если мне при этом будут подавать ключи (как в том анекдоте).
Одна из тех причин почему выбор пал именно на Си, это самодостаточность. Программе на Си не нужны виртуальные движки как Java, PHP или NodeJS с их версионностью, багами, деприкейтами и legacy, не нужны кеширующие прекомпиляторы и другие костыли. Не нужны зависимости, зависящие от зависимых зависимостей в которых постоянно находят чужие интружены (сорян, каламбур сам по себе напрашивался, навеянный dependencies в NodeJS и проблемами с ними связанными).
В Си тоже широко используются библиотеки, но это не разрушает самодостаточности. Чем выше самодостаточность — тем меньше потенциальных точек отказа, тем выше стабильность, предсказуемость и контролируемость. То, чего мне не хватало в DevOps — ощущения стабильности, предсказуемости и контроля, я в гораздо большей степени нашёл в Си-разработке.
На работе у меня код, который писался в течение 35 лет и насчитывает около 170 000 строк. Сложный, стабильный и с нулевым покрытием юнит-тестами (тогда TDD был не в фаворе) К тому же, код изначально писался и развивался под AIX (была такая OS, а может и есть до сих пор) которая, кстати, big-endian с нативной кодировкой EBCDIC вместо привычной нам ASCII. И что? И ничего! За пару месяцев весь этот код без особых последствий силами двух очень хорошо разбирающихся программистов портировали на Linux x86_64 который уже little-endian. Теперь софт продолжает успешно трудиться на фундаментально другом железе, другой операционке и собранный абсолютно другим компилятором.
В чём тут принципиальное отличие от философии DevOps? Нет лишних слоёв абстракций! Всё максимально просто, поэтому надёжно как до сих пор работающий лом, доставшийся в наследство от прадедушки вместе с сарайчиком, в котором стоят пластиковые китайские грабли, гнущиеся в нужных и, главное, в ненужных местах на все 180 градусов, как современные облачные технологии, прогибающиеся под прихоти в самые замысловатые позы.
DevOps как набор идей логичен. Но конкретная работа DevOps-инженера во многих компаниях превращается в жизнь на стыке чужих абстракций, чужих багов, чужих API, чужих бизнес-решений и твоей персональной ответственности. Лично мне этот тип нагрузки оказался разрушителен.
Пишет! :-D
Даже фреймворки есть, чтобы не приходилось мудрить на примитивном уровне с printf(“%s”,"<html "); и даже их несколько. Прекрасно себе живут и пользуются популярностью, потому что софт на их базе потребляет в 10-20 раз меньше ресурсов по сравнению аналогичными решениями на других ЯП. Там где под Java web-приложение нужно 20 серверов под такую же логику программе на Си потребуется только два. Не всегда, не везде, не бесплатно по трудозатратам, но можно и это совершенно реально!
И бизнесу хорошо и нам есть что намазать на бутерброд.
У меня две домашние машины с Linux Gentoo. Два ядра из считающихся абсолютно стабильными веток. Между ними 3 месяца разницы и несколько минорных номеров. Одно ядро вообще беспроблемное — всё работает просто идеально. На второй машине обновил на более свежее и начались проблемы — через рандомное время крэшится всё что связано с иксами и сеансами пользователя. Подозреваю видеоподсистему, но надо сидеть разбираться. Пока просто откатил на то стабильное, трёхмесячной давности и всё опять в порядке.
К чему это я… Linux это такая же программа как всё остальное. И она может быть одним из сотен тысяч источников проблем для DevOps инженера. Не становитесь DevOps инженерами! И даже сисадминами не надо! :-)
Зачем это всё? Зачем только трудов и опасной ответственности? Слишком много рисков по сравнению с работой в сфере программирования! Не становитесь DevOps инженерами! :-D
Обнял. Всем желаю успехов от души! И DevOps, и простым пользователям.
Сделает! СДЕЛАЕТ! Окружение решает многое, если не всё! Сейчас обосную:
Предположим, Вы — бомж. У вас один уровень решаемых задач и проблем: где найти мусорник с едой и так, чтобы не побили «конкуренты»? Где переночевать при минус 15 (под мостом, как обычно не прокатит)? Как накатить чтобы забыться от всего этого и не думать о том, что будет завтра?
Теперь сравним с уровнем решаемых задач если Вы рядовой гражданин состоявшейся, социально-ориентированной страны без лишних потрясений: какая школа лучше ребёнку? Где комфортнее климат? Какое хобби лучше для души? Спорт? У какого работодателя интереснее задачи и выгоднее оплата? Какие интересные события можно организовать на завтра?
Есть такая мудрость, о которой сразу вспоминается в такие моменты: «Нельзя перейти море говна и не заляпаться, даже если ты в резиновых сапогах». Лучше сделать всё, чтобы держаться от такого «моря» подальше. Поэтому да, эмиграция — сделает жизнь лучше!
Можно вступить в секту "с" (без единицы) :-D https://habr.com/ru/articles/811429/
Сто́ит напомнить, что врать в завышать показатели — это часть культуры Китая. Из-за чего они вымирали миллионами во времена мао. Если верить их официальным заявлениям, так они и термояд уже давно победили, и в другие галактики летают на своих EmDrive. Поэтому понять что у них происходит с технологическими прорывами на самом деле очень и очень нелегко.
Потому, что для внедрения любых инноваций нужны хорошо мотивированные и высококвалифицированные кадры, которые будут управляться стабильными бизнесами, владельцы которых уверены в своём "завтра", а так же в том, что их авторские права будут соблюдаться и защищатся международным правом. С учётом ТЕКУЩЕЙ обстановки, в пучину которой себя втянула страна, ничего из этого нет и не будет ещё десятилетиями.