Я хочу использовать новый потоковый сервер для своего веб-сайта, на котором обычно хранятся видео и аудио файлы. Но как нам поддерживать резервную копию потокового сервера, если размер хранилища увеличивается день ото дня.
Как правило, на серверах баз данных, таких как Sql Server, можно легко создавать резервные копии и очень легко восстанавливать их, поскольку они не занимают много места для приложений среднего диапазона.
С другой стороны, как мы можем сделать резервную копию потокового сервера? Если сервер выходит из строя, должен быть альтернативный сервер / решение, которое должно уменьшить время простоя сервера.
Каким образом внутренняя архитектура YouTube справляется с этим?
Что мы делаем, так это наличие нескольких сетей FC SAN, каждая из которых синхронизирована друг с другом в разных центрах обработки данных, каждая из которых подключена к банкам серверов, выступающих в качестве «исходных» серверов, переводящих хранилище FC в NFS или CIFS / SMB. Затем эти серверы разделяются на блоки VIP с балансировкой нагрузки, которые, в свою очередь, подают блоки веб-серверов с одинаковыми VIP-адресами, которые затем представляются через FW / LB внешнему миру.
Фактический контент периодически переносится из одного или нескольких блоков FC SAN в выделенный блок SAN, который затем копируется на диск на другом сайте, ленты затем сохраняются в Iron Mountain. Я занимаюсь потоковым бизнесом :)
Нет никаких сокращений с контентом, он большой, и вам просто нужно с ним разобраться. На вашем месте я бы установил выделенную машину для резервного копирования с доступным для нее большим участком диска и использовал rsync, чтобы гарантировать, что у вас есть копия каждого файла в основном хранилище содержимого, даже если это неизбежно закончится как надмножество ваши данные в реальном времени. Затем сделайте резервные копии на диск или на магнитную ленту этой машины и периодически удаляйте устаревшие данные, чтобы ими было управлять.
Да, и youtube не выполняет должным образом резервное копирование любого обычного пользовательского контента, их дизайн гарантирует, что у них есть несколько копий, распределенных по всему миру, но это больше для производительности, чем для возможностей восстановления. Они делают резервные копии своего собственного контента или любого другого контента, за развертывание которого им платят, но это крошечная капля в море по сравнению со всем контентом, который они не имеют договорных обязательств хранить.
Теперь вы понимаете, почему нелегко настроить сервис потокового видео / аудио и обеспечить его надежность. Чтобы получить решение для полного резервного копирования, вам необходимо:
Если вы хотите сократить время простоя, вам необходимо добавить как минимум в два раза больше серверов, чем у вас есть для исходного решения, а также способ управления этой сетью. Стоимость будет как минимум в 2 раза выше оригинального решения.
Как отметил Chopper3, вы можете встроить в инфраструктуру необходимость делать «резервные копии», потому что при добавлении контента оно автоматически зеркалируется.
Предположим, один из ваших вопросов: «Каким образом серверная архитектура YouTube справится с этим». хотя вы никогда не использовали вопросительный знак в своем сообщении, ответ на этот вопрос заключается в том, что Google невероятно огромен и имеет множество серверов, разбросанных по всему миру, и вы можете быть уверены, что данные хранятся на нескольких машинах, поэтому в случае, если один из них выйдет из строя, данные могут продолжаться.
Обычные планы резервного копирования включают в себя резервное копирование за пределами площадки, но если вам нужно иметь высокое время безотказной работы, вам могут потребоваться как внешние, так и локальные резервные копии, чтобы вы могли быстро восстановить с локального, хотя, если когда-либо произойдет какая-либо авария на DC, вы будете придется использовать сторонние.
Кто-то упомянул резервные копии на магнитной ленте, хотя я бы не советовал их использовать, поскольку вам, похоже, на самом деле не нужны архивы данных, и вы, вероятно, просто хотите иметь возможность синхронизировать свои данные с другим сервером, чтобы иметь резервную копию. Есть полезные инструменты, такие как rsync, которые могут синхронизировать данные и загружать только измененные файлы, избавляя вас от необходимости делать полное резервное копирование.
Есть способы, которыми вы можете чрезмерно усложнить его, и способы сжечь деньги, создав большую избыточность, но что-то мне подсказывает, что вы не можете себе этого позволить и вам не нужны хлопоты по управлению слишком большим количеством машин.