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

Для того, чтобы исключить подобные проблемы в будущем, Internet Archive объединил усилия с Cloudflare. Сайты, которые обслуживаются при помощи этого сервиса, станут участниками программы Cloudflare Always Online. Эти сайты будут синхронизироваться с базой данных Архива интернета, благодаря чему всегда будут доступны для пользователей.

Участие в программе нужно будет подтверждать. Те пользователи Cloudflare, кто пожелает воспользоваться этой возможностью, смогут настроить автоматическую отправку имени хоста и адресов страниц сайта в Internet Archive. Сервис будет их архивировать и выдавать последнюю сохраненную копию ресурса пользователю в том случае, если напрямую сайт не доступен.

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

Архив интернета предоставляет специальные условия для сайтов, которые являются участниками программы Cloudflare Always Online. Их копии будут регулярно сохраняться в базе сервиса с периодичностью в 5-30 дней.

На данный момент в Internet Archive доступно около 330 млрд копий различных ресурсов. Число только зарегистрированных пользователе больше 10 млн человек. Благодаря Архиву интернета пользователи могут ознакомиться с сайтами, которые уже не существуют. Есть и возможность оценить ранние версии самых разных интернет-ресурсов.

Кроме сайтов, сервис сохраняет и мультимедиа-контент, включая музыку. Еще Internet Archive сохраняет книги, что недавно вызвало недовольство правообладателей. Сразу четыре коммерческих издательства потребовали удалить цифровые копии полутора миллионов книг с проекта Открытая библиотека. Проект Открытая библиотека работает с 2006 года. В 2020 году из-за пандемии коронавируса Архив Интернета объявил о расширении проекта: с 31 марта пользователи могут скачивать любые книги неограниченное количество раз.

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

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

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

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

Вымирание ссылок

Все составные вещи недолговечны. Стремитесь к собственному освобождению с особым усердием.
Последние слова Будды Шакьямуни

Величина вымирания вызывает возмущение. Вот взгляд Википедии:

В эксперименте 2003 года Фетерли (с соавторами) обнаружил, что примерно одна ссылка из 200 исчезает каждую неделю из интернета. МакКоун (с соавторами, 2005) обнаружил, что половина URL, указанных в статьях журнала D-Lib Magazine, не были доступны через 10 лет после публикации, а другие исследования показали даже худшее вымирание ссылок в научной литературе [5] [6]. Нельсон и Аллен [7] изучали вымирание ссылок в цифровых библиотеках и нашли, что около 3 % объектов были недоступны после одного года. В 2014 владелец сайта закладок Pinboard Мацей Цегловский сообщал, что довольно стабильная доля в 5 % ссылок вымирает за год [8]. Исследование ссылок из каталога Yahoo! показало период полураспада случайной страницы в 20162017 годах (вскоре после того, как Yahoo! перестала публиковать этот каталог) около двух лет [9].

Брюс Шнайер вспоминает, что за девять лет у одного его друга сломалась половина ссылок на странице (и не то чтоб в 1998 году дела обстояли лучше), и что он сам порой выкладывал ссылку а через пару дней она уже не работала. Виторио перебрал свои закладки из 1997 года в 2014-ом и обнаружил, что 91% не работает, а половины нет даже в Internet Archive. Эрни Смит взял книгу про интернет из 1994 года и нашёл в ней целую одну работающую ссылку. Internet Archive считает, что среднее время жизни страницы в интернете 100 дней. Статья в Science утверждает, что учёные обычно не вставляют URLы в научные публикации, а когда вставляют 13% не работает через два года. Французская компания Linterweb изучала внешние ссылки во франкоязычной Википедии и обнаружила, что в 2008 году 5% были мертвы. Англоязычная Википедия пережила вспышку битых ссылок в 2010-январе 2011, когда их число выросло от нескольких тысяч до ~110 000 из ~17.5 миллионов. На некогда легендарной Million Dollar Homepage, последняя ссылка на которой была поставлена в январе 2006 и стоила 38 тысяч долларов, к 2017 не меньше половины ссылок были мертвы или захвачены киберсквоттерами (с неё до сих пор идёт трафик, так что некоторые адреса могут иметь ценность). Сайт закладок Pinboard отмечал в августе 2014, что 17% 3-летних ссылок и 25% 5-летних не открываются. И так далее, и тому подобное, и прочее в том же духе.

Ссылки сыплются даже в более-менее стабильных, модерируемых и не разорившихся системах. Хотя Твиттер как таковой прекрасно себя чувствует, 11% твитов времён Арабской Весны не открывались уже через год. А иногда незаметно исчезают сразу огромные объёмы данных: например, администрация MySpace где-то потеряла всю музыку, загруженную с 2003 по 2015, и объявила, что они перестроили MySpace с нуля и решили перенести часть пользовательского контента со старой версии. Правда, часть загрузок 2008-2010 была восстановлена и выложена на IA анонимным исследователем.

Я хочу, чтобы мои данные хотя бы пережили меня; скажем, дожили до 2070. По состоянию на 10 марта 2011 года (прим. пер.: дата выхода первой версии этого текста. Последний апдейт датируется 5 января 2019), у меня на сайте примерно 6800 внешних ссылок, из них 2200 не на Википедию. Даже при минимальной оценке в 3% умирающих ссылок в год, до 2070 доживут немногие. Если шанс выживания данной конкретной ссылки в данный год 97%, то вероятность её не потерять до 2070 равна 0.97^(2070-2011)0.16. 95-процентный доверительный интервал для такого биномиального распределения подсказывает, что ~336-394 ссылки из 2200 будут работать в 2070 году. Если использовать верхнюю оценку смертности в 50% ссылок в год то в 2070 году, скорее всего, не останется ни одной.

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

Если мы хотим заархивировать данную конкретную страницу то всё просто. Нужно либо пойти на Internet Archive и нажать там соответствующую кнопку, либо распечатать страницу в PDF прямо из браузера. Для сохранения более сложных страниц есть специальные плагины, например ScrapBook. Но я захожу и ссылаюсь на огромное количество страниц, так что сохранять каждую из них вручную будет тяжеловато. Нужна система, которая бы автоматически обеспечивала корректные ссылки на все страницы, которые могут мне когда-нибудь понадобиться.

Поиск битых ссылок

Одну весну за другой
цветы излагают Закон,
не говоря ни единого слова,
но уяснив его суть
из срывающего их ветра
Сётэцу

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

@monthly linkchecker --check-extern --timeout=35 --no-warnings --file-output=html \                      --ignore-url=^mailto --ignore-url=^irc --ignore-url=http://.*\.onion \                      --ignore-url=paypal.com --ignore-url=web.archive.org \                     https://www.gwern.net

В таком виде эта команда вернёт кучу ложноположительных сигналов. Несколько сотен якобы битых ссылок будут найдены на одной только Википедии, потому что я ссылаюсь на редиректы; кроме того, linkchecker читает robots.txt и не может проверить заблокированные в нём адреса. Это можно исправить, добавив в ~/.linkchecker/linkcheckerrc "ignorewarnings=http-moved-permanent,http-robots-denied" (полный список классов предупреждений есть в linkchecker -h)

Чем раньше битая ссылка найдена, тем раньше можно что-то с ней сделать. Что именно?

Удалённое кеширование

Всё, что ты постишь в Интернете, будет существовать до тех пор, пока оно тебя позорит, и исчезнет, как только оно тебе понадобится.
с сайта Ycombinator

Можно попросить кого-нибудь другого хранить кэши всех нужных нам страниц. Как раз на такой случай есть несколько веб-архивов:

1. The Internet Archive
2. WebCite
3. Perma.cc (сильно ограничен)
4. WikiWix (но у него есть конкретная функция бэкапить исходящие ссылки Википедии так что весь остальной интернет его интересует довольно мало).
5. Archive.is
6. Pinboard предоставляет архивацию за 25$ в год
7. Hiyo.jp и Megalodon.jp (но они на японском) Прим.пер.: по состоянию на март 2021 первая ссылка не открывается. Что забавно, локальный архив Гверна честно отдаёт мне сохранённую главную страницу сервиса, но воспользоваться ей уже вряд ли получится.

Есть и другие архивы, но они могут быть недоступны (например, кэш Google хоть я и не верю, что Гугл и правда удаляет все свои кэши, отдавать их пользователям он точно перестаёт) или разнообразные коммерческие / государственные архивы (которые по определению недоступны публике ни для пополнения, ни для использования, и вообще мы про них знаем преимущественно по историям типа знакомый моего знакомого знает одного парня, который работал в некой неназванной федеральной организации, и вот этот парень рассказывал, что у них там есть собственный Wayback Machine).

Кстати, хранить в этих архивах собственный сайт тоже неплохая идея:

• Бэкапы это хорошо, но локальный бэкап тоже может случайно погибнуть (это я из собственного опыта говорю), так что неплохо бы иметь удалённые копии.
• Уменьшается пресловутый автобусный фактор: если завтра я попаду под автобус, то кто и как получит доступ к моим бэкапам? У кого будет время и желание в них потом разбираться? А про IA люди в целом понимают, что там и как, к тому же для работы с ним созданы специальные инструменты.
• Фокус на бэкапе самого сайта отвлекает внимание от необходимости бэкапить то, на что ты ссылаешься. Многие страницы мало чего стоят, если ссылки в них перестали открываться, а скрипты / демоны для архивации можно настроить так, чтобы они автоматически подтягивали всё необходимое.

Первый бот, который я для этого написал, Wikipedia Archiving Bot, просто кидал запросы в WebCite, Internet Archive и Archive.is. Потом он был модифицирован в вики-плагин gitit, который прицепляется к коду сохранения страницы и пытается автоматически сохранить каждую свежедобавленную ссылку (interwiki.hs). Если вам плевать на приватность то Alexa Toolbar тоже умеет в автосохранение на Internet Archive.

В конце концов я написал archiver, простенький демон, который мониторит текстовый файл с URLами. Исходники можно скачать через

git clone https://github.com/gwern/archiver-bot.git

Archiver состоит из библиотеки, которая по сути является просто обёрткой вокруг соответствующих HTTP-запросов, и исполняемого файла, который берёт список адресов, сообщает Internet Archive, что их не мешало бы сохранить, потом удаляет соответствующую строку из файла и продолжает в том же духе, пока файл не опустеет.

Вызов выглядит так:

archiver ~/.urls.txt gwern@gwern.net

. Он у меня когда-то крашился по непонятным причинам, так что я завернул команду в while true:

while true; do archiver ~/.urls.txt gwern@gwern.net; done

. Потом я завернул его ещё и в сессию GNU screen:

screen -d -m -S "archiver" sh -c 'while true; do archiver ~/.urls.txt gwern@gwern.net; done'

. Ну и запускаем не руками, а через cron, так что в итоге получается:

@reboot sleep 4m && screen -d -m -S "archiver" sh -c 'while true; do archiver ~/.urls.txt gwern2@gwern.net  "cd ~/www && nice -n 20 ionice -c3 wget --unlink --limit-rate=20k --page-requisites --timestamping -e robots=off --reject .iso,.exe,.gz,.xz,.rar,.7z,.tar,.bin,.zip,.jar,.flv,.mp4,.avi,.webm --user-agent='Firefox/4.9'" 500; done'

Локальное кэширование

Удалённые архивы это хорошо, но у них есть один фатальный недостаток: архивные сервисы не поспевают за ростом интернета и большей части материалов там может не быть. Ainsworth et al. 2012 показали, что менее 35% веб-страниц заархивированы хоть где-нибудь, и подавляющее большинство из них сохранены только в одном архиве. К тому же и сами архивы в принципе могут умереть вместе со всем их содержимым. Так что локальное кэширование тоже должно быть.

Самый фундаментальный подход взять кэширующее прокси, которое будет сохранять буквально весь ваш веб-трафик. Например, Live Archiving Proxy (LAP) или WarcProxy будет писать WARC-файлы для каждой посещённой через HTTP веб-страницы. Zachary Vance пишет, что можно настроить локальный HTTPS-сертификат и добраться до содержимого HTTPS-страниц за счёт MitM-атаки на собственный трафик.

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

Раньше я использовал скрипт с потрясающе оригинальным названием local-archiver:


Код не самый красивый, но вроде всё понятно.

1. Выгружаем адреса из SQL-файла Firefox и скармливаем их wget. Это не самый подходящий инструмент для скачивания сайтов: он не может запускать JS/Flash, скачивать потоковое видео и прочая и прочая. Весь джаваскрипт будет просто скачан в виде файла, который, скорее всего, перестанет исполняться через пару лет, а динамически подгружаемый контент не сохранится. С другой стороны, это не такая уж большая проблема, потому что на практике мне нужен в основном как раз статический контент (а JS по большей части обеспечивает только ненужные свистелки), а видео можно бэкапить руками через youtube-dl. Если страница приватная и без логина не открывается то можно вытащить куки из Firefox специальным аддоном, скормить их wget через ключ --load-cookies и всё будет хорошо. Так что в целом wget мне хватает.
2. Скрипт дробит список URL на множество файлов и параллельно запускает бэкапы на каждом из них, потому что wget не умеет одновременно качать с нескольких доменов и может подвиснуть.
3. filter-urls это ещё один скрипт, удаляющий адреса, которые не надо бэкапить. По сути это просто гора костылей:
   

    #!/bin/shset -euo pipefailcat /dev/stdin | sed -e "s/#.*//" | sed -e "s/&sid=.*$//" | sed -e "s/\/$//" | grep -v -e 4chan -e reddit 
   

   
   
4. Удаляются большие файлы, типа видео / аудио. У меня это обычно подкасты.

Довольно быстро я понял, что у такого решения полно недостатков. Его надо не забывать запускать, оно пишет единственный архив (так что его нельзя поставить в cron, иначе повторяющиеся страницы съедят кучу места на жёстком диске), оно может подвиснуть, страницы могут умереть после посещения, но до сохранения, файлы в 4+ мегабайта могут оказаться полезными PDFками и прочая и прочая. Что особенно важно, я хочу бэкапиться как локально, так и удалённо.

Так что я сел писать archiver, который бы постоянно крутился в фоне и собирал адреса, бэкапил бы в Internet Archive и вёл себя более разумно с большими медиафайлами.

Я добавил туда ещё пару фич: во-первых, он принимает в качестве третьего аргумента произвольную sh-команду, которой будет отдана ссылка. Это полезно, если вам хочется что-нибудь делать со всеми сохранёнными страницами (например, вести логи).

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

Расход ресурсов

Кажется, что такой локальный бэкап будет пожирать огромные ресурсы, но на самом деле за год набирается 30-50 Гб. Меньше, если настроить игнорирование страниц более жёстко, больше, если сохранять сайты целиком (а не только посещённые страницы). В долгосрочной перспективе всё это вполне жизнеспособно: с 2003 по 2011 средняя страница увеличилась в 7 раз (что неприятно), но цена хранения за тот же период упала в целых 128 раз. По состоянию на 2011 год, за 80 долларов можно купить минимум пару терабайт, так что гигабайт места на жёстком диске стоит около 4 центов. Получается, что весь бэкап стоит один-два доллара в год. На самом деле больше, потому что всё это надо хранить в нескольких копиях, но всё равно копейки. К тому же нам тут повезло: большая часть документов изначально цифровая и может быть автоматически перенесена с диска на диск или конвертирована в другой формат. Обратная совместимость в браузерах неплохо работает даже с документами из начала девяностых, и даже если что-то не откроется сразу, об этой проблеме можно будет думать, когда и если она действительно возникнет. Разумеется, если нужные данные зашиты в анимацию Adobe Flash или динамически подтягиваются из облака то они пропали, но это всё ещё куда меньшая боль, чем если бы мы пытались сохранять программы и библиотеки (что потребовало бы полного стека двоично совместимых виртуалок или интерпретаторов).

Размер можно и уменьшить: tar-архив, пожатый 7-zip на максимальных настройках, примерно впятеро меньше исходника. Ещё процентов 10 можно убрать, найдя идентичные файлы через fdupes и подменив их на хардлинки (на веб-страницах полно абсолютно идентичного джаваскрипта). Хорошая фильтрация тоже не помешает. Например, за период с 2014-02-25 по 2017-04-22, я посетил 2,370,111 URL (в среднем 2055 в день); после фильтрации осталось 171,446 URL'ов, из которых всего 39,523 уникальных (34 в день, 12,520 в год).

По состоянию на 2017-04-22 архивы за 6 лет весят всего 55 Гб за счёт компрессии, агрессивной фильтрации, удаления больших доменов, которые и так бэкапит Internet Archive, и прочих ручных оптимизаций.

Источники URL

Список страниц, которые надо сохранить, заполняется из нескольких источников. Во-первых, есть скрипт под названием firefox-urls:


(filter-urls тот же самый, что и в local-archiver. Если я не хочу сохранять страницу локально, то я и в удалённый архив её не стану отправлять. Более того, у WebCite есть ограничение на число запросов, так что archiver еле справляется с нагрузкой и не надо грузить его ещё и пустой болтовнёй на форчане).

Этот скрипт запускается раз в час по крону:

@hourly firefox-urls >> ~/.urls.txt

Посещённые с последнего запуска адреса оказываются в файле и archiver их увидит при следующем запуске, так что всё, что я читаю, сохраняется навечно. Если у вас Chromium, то существуют аналогичные скрипты от Zachary Vance для извлечения истории и закладок.

Второй и, пожалуй, более полезный источник парсер Markdown. Все ссылки аналогичным образом выдираются из моих документов (link-extractor.hs), отправляются в файл списка, и рано или поздно они отправляются в архивы.

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

linkchecker --check-extern -odot --complete -v --ignore-url=^mailto --no-warnings http://www.longbets.org | fgrep http | fgrep -v -e "label=" -e "->" -e '" [' -e '" ]' -e "/ " | sed -e "s/href=\"//" -e "s/\",//" -e "s/ //" | filter-urls | sort --unique >> ~/.urls.txt

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

Благодаря связке linkchecker и archiver, на Gwern.net почти нет битых ссылок. Когда они обнаруживаются, у меня уже подготовлено множество запасных вариантов:

1. Найти работающую версию страницы
2. Подставить копию из Internet Archive
3. Подставить копию из WebCite
4. Подставить копию из WikiWix
5. Использовать локальный дамп.

Если страница сохранена вместе со всеми необходимыми файлами (wget --convert-links --page-requisites), её можно превратить в пригодный для распространения PDF. Это удобнее, чем полная папка HTML, картинок и CSS, потому что один файл это один файл, его проще передавать и на него проще ссылаться. Лично я пользуюсь wkhtmltopdf, и меня устраивает. Например, мёртвая страница http://www.aeiveos.com/~bradbury/MatrioshkaBrains/MatrioshkaBrainsPaper.html превратилась во вполне читаемый файл.

Фото 1. Один из дата-центров Internet Archive в Сан-Франциско

Internet Archive некоммерческая организация, которая с 1996 года сохраняет копии веб-страниц, графические материалы, видео- и аудиозаписи и программное обеспечение. Каждый может зайти в Wayback Machine и посмотреть, как выглядел Хабр в 2006 году или Яндекс в 1998 году, хотя загрузка архивных копий занимает около минуты (это не для реализма 90-х, а по техническим причинам, см. ниже).

Архив быстро растёт. Сейчас объём всех накопителей достиг 200 петабайт. Но Internet Archive принципиально не обращается к стороннему хостингу или облачному сервису вроде AWS. У некоммерческой организации собственные дата-центры, свои серверы и свои инженеры. Это гораздо дешевле, чем услуги AWS.

Архив Интернета против облаков

Технические подробности серверного устройства Internet Archive раскрыл Джона Эдвардс (Jonah Edwards), руководитель инженерной группы Core Infrastructure Team.

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


Четыре дата-центра Internet Archive располагаются в Сан-Франциско, Ричмонде и Редвуд-Сити (это пригороды Сан-Франциско)

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

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

Инфраструктура

Что представляет собой инфраструктура, которой управляет Core Infrastructure Team? На февраль 2021 года цифры такие:

• 750 серверов, возраст до 9 лет;
  
• 1300 виртуальных машин;
  
• 30 000 устройств хранения данных;
  
• более 20 000 жёстких дисков в парах друг с другом (paired storage), обычно пара разнесена по дата-центрам или странам для надёжности;
  
• общий объём накопителей почти 200 петабайт.

Разумеется, техника постепенно обновляется. На смену старым накопителям приходят новые. Например, маленькие диски на 2 и 3 терабайта полностью вышли из обращения в 2017 и 2018 годах, соответственно, а с прошлого года постоянно растёт доля дисков на 16 ТБ.

Как показано на графике ниже, несмотря на увеличение ёмкости накопителей, общее число HDD тоже постепенно растёт: за три года оно выросло с 15 тыс. до 20 тыс.


Количество жёстких дисков разного объёма на серверах Internet Archive

Диски реплицируются по дата-центрам, для производительности контент по запросу выдаётся одновременно со всех копий. Все элементы Архива представляют собой директории на дисках. Веб-страницы Wayback Machine хранятся в файлах WARC (Web ARChive, сжатые файлы Web Archive). При запросе отдельной страницы её нужно извлечь из середины архива WARC, а если страница требует загрузки дополнительных ресурсов, то процесс повторяется. Это одна из причин, почему полная загрузка страниц из Wayback Machine достигает 90 секунд, хотя закэшированные копии и популярный контент загружаются быстрее.



Для надёжности копии Архива хранятся не только в Сан-Франциско, но и ещё в нескольких локациях по всему миру, в том числе в Амстердаме (Нидерланды) и Новой Александрийской библиотеке (Египет).

В 1996 году первые серверы Internet Archive подняли на недорогих компьютерах из стандартных комплектующих: по сути, на обычных десктопах под Linux. Хотя инфраструктура сильно выросла, в качестве операционной системы всегда использовали только Linux. С 2004 года все серверы перешли на Ubuntu, сейчас продолжается миграция на Ubuntu 20.4 LTS (Focal Fossa).

Объём Архива

В последнее время объём Архива возрастает примерно на 25% в год, сейчас это соответствует 56 петабайтам в квартал. С учётом резервных копий нужно добавлять накопителей на 1012 петабайт в квартал.

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

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

Internet Archive возлагает большие надежды на новые технологии записи данных, такие как HAMR (heat-assisted magnetic recording), чтобы ёмкость HDD увеличивалась ещё быстрее. Технология HAMR предусматривает предварительное нагревание магнитной поверхности лазером в процессе записи, что позволяет значительно уменьшить размеры магнитной области, хранящей один бит информации и увеличить плотность записи. Нагрев выполняется с помощью лазера, который за 1 пс разогревает область записи до 100 C.

Разработка этой технологии затянулась на 15 лет, но в январе 2021 года были официально представлены первые диски HAMR на 20 ТБ. Пока что они официально поставляются только избранным клиентам в рамках фирменного сервиса Seagate Lyve, но вскоре должны появиться в свободной продаже.

Seagate обещает, что HAMR позволит наращивать ёмкость HDD на 20% в год. Поэтому в ближайшее время можно ожидать модель на 24 ТБ, а в будущем диски на 30 и 50 ТБ. Internet Archive тоже надеется на это и внимательно следит за последними разработками.

На текущем размере дисков понадобится 15 вот таких серверных стоек, чтобы разместить одну копию Архива:


У Internet Archive 750 серверов и 20 000 жёстких дисков

Сейчас в дата-центрах установлено 75 серверных стоек, что обеспечивает некоторый запас и избыточное копирование.

По состоянию на февраль 2021 года на серверах хранились копии 534 млрд веб-страниц, 16 млн аудиозаписей, 8,7 млн видеозаписей фильмов, клипов и телепередач, 3,8 млн изображений, 629 тыс. компьютерных программ, более 29 млн книг и текстов, в том числе 72 771 текст на русском языке.



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

Internet Archive поддерживает API для внешних сервисов. Например, сторонний сервис может забирать контент из хранилища и показывать его на своём сайте или в приложении. Можно строить собственные каталоги на базе этого хранилища, эксплуатируя IA просто как удалённый бесплатный хостинг файлов с хотлинками. Подобную модель использует книжный каталог Open Library на базе Internet Archive. Хотлинки и модель подобной эксплуатации собственных ресурсов поощряется со стороны Архива. Кстати, аналогичные правила действуют в Wikimedia Commons: холинкинг разрешён и даже поощряется, что недавно вызвало казус с фотографией цветка: по непонятной причине ежедневно в сеть Wikimedia Commons поступало около 90 млн одинаковых запросов на получение одного файла AsterNovi-belgii-flower-1mb.jpg. Будем надеяться, что у Internet Archive таких инцидентов не случится.

Сеть

В 2020 году Internet Archive пережил серьёзный рост количества запросов и объёма внешнего трафика с 40 до 60 Гбит/с. Из-за пандемии коронавируса и самоизоляции ресурсы Архива стали более востребованы. Количество запросов росло так быстро, что в определённый момент маршрутизаторы Internet Archive перестали справляться с нагрузкой, пришлось делать апгрейд сетевой инфраструктуры быстрее, чем планировалось. Сейчас веб-сайт входит в топ-300 крупнейших сайтов интернета.

Работа на собственных серверах имеет и свои недостатки. Основные причины сбоев Internet Archive обрывы оптоволокна из-за строительных работ в городе, сбои энергоснабжения, случайные провалы напряжения в сети. Впрочем, прошлый год сайт завершил с аптаймом 99,9%.



Internet Archive планирует расширять внешний канал. Ожидается, что в ближайшее время внешний трафик вырастет до 80 Гбит/с.

Примерно так выглядит дизайн внутренней сети:



Дата-центры подключены к нескольким провайдерам первого уровня (Tier 1) и соединены между собой по оптоволокну с применением технологии плотного спектрального уплотнения (DWDM). Локальные университетские сети подключаются к этому кольцу напрямую через локальные точки обмена трафиком.

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

Прокладка новых кабелей по Сан-Франциско весьма хлопотное и дорогое дело. Приходится перекладывать асфальт на автомобильных дорогах и тротуарах. К счастью, Internet Archive удалось получить официальный статус библиотеки, что даёт доступ к государственным субсидиям, в том числе к бюджету Федеральной комиссии по связи США (FCC) на подключение всех библиотек к интернету. Таким образом, львиную долю расходов на прокладку, обслуживание оптоволокна и трафик оплачивает FCC по программе E-Rate Universal Service Program.

С 2005 года Internet Archive начал проект Open Library по сканированию книг. С одной стороны, это действительно важный общественный проект. С другой стороны, он позволил получить государственные льготы и финансирование в качестве публичной библиотеки.

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

Планы на будущее

Инженеры Internet Archive сейчас обдумывают варианты использования SSD и GPU в основных серверах, чтобы увеличить их производительность. Главная проблема здесь в том, что все дата-центры находятся в стеснённых городских условиях Сан-Франциско и пригородов с очень ограниченными возможностями охлаждения (см. фото 1). Так что каждый апгрейд требуется хорошо обдумать: не приведёт ли он к повышению температуры.

Интересно наблюдать за ростом инфраструктуры Internet Archive с увеличением количества серверных стоек. Есть подозрение, что рано или поздно наступит момент, когда сложность поддержания своей инфраструктуры превысит некий порог и библиотека откажется от собственных дата-центров. Но пока что инженеры Core Infrastructure Team успешно справляются с работой.

В зависимости от методологии расчёта, хранение данных в собственных дата-центрах Internet Archive обходятся в 25 раз дешевле, чем в облаке. И это только хранение. Сложно даже посчитать, сколько будет стоить круглосуточный исходящий трафик 60 Гбит/с на AWS. Вероятно, он обойдётся даже дороже, чем хранение 200 петабайт.

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

---

На правах рекламы

Эпичные серверы это надёжные VDS на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрой файловой системой, используем исключительно NVMe диски от Intel. Попробуйте как можно быстрее!