ПРОЕКТИРОВАНИЕ СИСТЕМЫРЕЗЕРВНОГО КОПИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ ОБЛАЧНЫХ СЕРВИСОВ
Выполнила:
Наскрипняк Екатерина Сергеевна
Студент: 3511 группы
Специальность: Компьютерные сети
Руководитель: К.И. Дятлов
Оценка
Санкт-Петербург, 2018
| ПРАВИТЕЛЬСТВО САНКТ-ПЕТЕРБУРГА КОМИТЕТ ПО НАУКЕ И ВЫСШЕЙ ШКОЛЕ Санкт-Петербургское государственное бюджетное образовательное учреждение среднего профессионального образования «ПЕТРОВСКИЙ КОЛЛЕДЖ» (СПб ГБОУ СПО «Петровский колледж») |
| Отделение информационно-промышленных технологий и судостроения |
ЗАДАНИЕ
для выполнения курсового проекта
Профессиональный модуль: Участие в проектировании сетевой инфраструктуры
Специальность: 09.02.01 Компьютерные сети
Группа, Ф.И.О. студента
3511, Наскрипняк Екатерина Сергеевна
Тема курсового проекта
ПРОЕКТИРОВАНИЕ СИСТЕМЫРЕЗЕРВНОГО КОПИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ ОБЛАЧНЫХ СЕРВИСОВ
Дата выдачи задания «___»__________ 20__г.
Проект/работа должен(на) быть сдан(а) не позднее «___»____________ 20___г.
Содержание курсового проекта
Введение
Актуальность темы КП. Цель, задачи КП.
Основные разделы
Аналитическая часть: определение и виды резервного копирования, основные характеристики «облачных» сервисов, виды, требования к ним, выбор оптимального облачного провайдера. Возможные методы реализации, выбор метода реализации, возможные затраты.
Заключение
Достигнутые цели проекта. Выполнение задач проекта. Сфера применения.
Руководитель курсового проекта/работы _________(_____________________)
Оглавление
Элементы оглавления не найдены.
ВВЕДЕНИЕ
Для организации общего рабочего процесса практически в любой компании используется комплекс общепринятых программных продуктов требующих работы клиент-серверной части. Так же централизованная работа организации подразумевает использование общих доступных ресурсов, таких как файловый обмен, почтовый сервис, или интернет. Для обеспечения работы тех или иных программных продуктов к компании необходимо использовать сервера хранения или обработки данных.
В процессе эксплуатации серверов приходится часто сталкиваться с необходимостью восстановления данных. Причин потери данных может быть очень много. Иметь возможность восстановить данные, это привилегия тех компаний, которые своевременно и серьезно подошли к решению таких ключевых моментов при работе с компьютерной техникой, как хранение и использование резервных копии различного рода компьютерной информации.
Для обеспечения бесперебойной работы компании, иногда требуется иметь возможность восстановить не только данные, но и работу всего сервера целиком. Целью данного курсового проекта является проектирование системы резервного копирования данных с применением облачных сервисов.
ЧТО ТАКОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ И ЗАЧЕМ НУЖНО
Резервное копирование — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения. Резервное копирование необходимо для возможности быстрого и недорогого восстановления информации (документов, программ, настроек и т. д.) в случае утери рабочей копии информации по какой-либо причине.
Требования к системе резервного копирования
· Надёжность хранения информации — обеспечивается применением отказоустойчивого оборудования систем хранения, дублированием информации и заменой утерянной копии другой в случае уничтожения одной из копий (в том числе как часть отказоустойчивости).
· Многоплатформенность - полноценное функционирование системы резервного копирования в гетерогенной сети предполагает, что её серверная часть будет работать в различных операционных средах и поддерживать клиенты на самых разных аппаратно-программных платформах.
· Простота в эксплуатации — автоматизация (по возможности минимизировать участие человека: как пользователя, так и администратора).
· Быстрое внедрение — простая установка и настройка программ, быстрое обучение пользователей.
Ключевыми параметрами резервного копирования являются:
· RPO — Recovery Point Objective;
· RTO — Recovery Time Objective.
RPO определяет точку отката — момент времени в прошлом, на который будут восстановлены данные, а RTO определяет время, необходимое для восстановления из резервной копии.
Виды резервного копирования
- Полное резервное копирование (Full backup)
Полное копирование обычно затрагивает всю систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется тогда, когда копирование большого объёма данных не влияет на работу организации. Для предотвращения большого объёма использованных ресурсов используют алгоритмы сжатия, а также сочетание этого вида с другими: дифференциальным или инкрементным. Полное резервное копирование незаменимо в случае, когда нужно подготовить резервную копию для быстрого восстановления системы с нуля.
- Дифференциальное резервное копирование (Differential backup)
При дифференциальном («разностном») резервном копировании каждый файл, который был изменён с момента последнего полного резервного копирования, копируется каждый раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все копии файлов делаются в определённые моменты времени, что, например, важно при заражении вирусами.
- Инкрементное резервное копирование (Incremental backup)
При добавочном («инкрементном») резервном копировании происходит копирование только тех файлов, которые были изменены с тех пор, как в последний раз выполнялось полное или добавочное резервное копирование. Последующее инкрементное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. Инкрементное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, а также данные всех последующих инкрементных резервных копирований. В отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
- Клонирование
Клонирование позволяет скопировать целый раздел или носитель (устройство) со всеми файлами и каталогами в другой раздел или на другой носитель. Если раздел является загрузочным, то клонированный раздел тоже будет загрузочным.
- Резервное копирование в виде образа
Образ — точная копия всего раздела или носителя (устройства), хранящаяся в одном файле.
- Резервное копирование в режиме реального времени
Резервное копирование в режиме реального времени позволяет создавать копии файлов, каталогов и томов, не прерывая работу, без перезагрузки компьютера.
- Холодное резервирование
При холодном резервировании база данных выключена или закрыта для потребителей. Файлы данных не изменяются и копия базы данных находится в согласованном состоянии при последующем включении.
- Горячее резервирование
При горячем резервировании база данных включена и открыта для потребителей. Копия базы данных приводится в согласованное состояние путём автоматического приложения к ней журналов резервирования по окончании копирования файлов данных.
Законы об авторском праве и других исключительных правах могут запрещать или ограничивать копирование. Иногда для резервного копирования предусматриваются исключения. Условия использования проприетарного программного обеспечения и других несвободных произведений также могут ограничивать или запрещать резервное копирование. Технические меры защиты от копирования затрудняют резервное копирование независимо от законов и условий.
- Удалённое резервное копирование данных — это сервис, предоставляющий пользователям систему для резервного копирования и хранения компьютерных файлов.
Системы удалённого резервного копирования обычно встраиваются в клиентскую программу, которая выполняется обычно один раз в день. Эта программа собирает, сжимает, шифрует и передаёт данные серверам поставщика услуг резервного копирования. Другим типом данного продукта, также доступном на рынке, является удалённая непрерывная защита данных (ТМВ).
ЧТО ТАКОЕ ОБЛАКО
Облачное хранилище данных (англ. cloud storage) — модель онлайн-хранилища, в котором данные хранятся на многочисленных распределённых в сети серверах, предоставляемых в пользование клиентам, в основном, третьей стороной. В отличие от модели хранения данных на собственных выделенных серверах, приобретаемых или арендуемых специально для подобных целей, количество или какая-либо внутренняя структура серверов клиенту, в общем случае, не видна. Данные хранятся и обрабатываются в так называемом «облаке», которое представляет собой, с точки зрения клиента, один большой виртуальный сервер. Физически же такие серверы могут располагаться удалённо друг от друга географически.
Преимущества
· Возможность доступа к данным с любого компьютера, имеющего выход в Интернет.
· Возможность организации совместной работы с данными.
· Высокая вероятность сохранения данных даже в случае аппаратных сбоев.
· Клиент платит только за то место в хранилище, которое фактически использует, но не за аренду сервера, все ресурсы которого он может и не использовать.
· Клиенту нет необходимости заниматься приобретением, поддержкой и обслуживанием собственной инфраструктуры по хранению данных, что, в конечном счёте, уменьшает общие издержки производства.
· Все процедуры по резервированию и сохранению целостности данных производятся провайдером «облачного» центра, который не вовлекает в этот процесс клиента.
Недостатки
· Безопасность при хранении и пересылке данных является одним из основных вопросов при работе с «облаком», особенно в отношении конфиденциальных и приватных данных. Так, например, провайдер имеет возможность просматривать данные клиента (если они не защищены паролем), которые также могут попасть в руки хакеров, сумевших взломать системы защиты провайдера.
· Надёжность, своевременность получения и доступность данных в «облаке» очень сильно зависит от многих промежуточных параметров, таких как: каналы передачи данных на пути от клиента к «облаку», надежность последней мили, качество работы интернет-провайдера клиента, доступность самого «облака» в данный момент времени. Если же сама компания, предоставляющая онлайновое хранилище, будет ликвидирована, клиент может потерять все свои данные.
· Общая производительность при работе с данными в «облаке» может быть ниже, чем при работе с локальными копиями данных.
· Абонентская плата за дополнительные возможности (увеличенный объем хранения данных, передача больших файлов и т. д.).
СРАВНЕНИЕ РАЗЛИЧНЫХ СИСТЕМ ОБЛАЧНОГО ХРАНЕНИЯ И ВЫБОР ОПТИМАЛЬНОЙ
1. Выбор площадки
Выбор облачного провайдера начинается с физической площадки дата-центра. Если ЦОД провайдера «становится», то отключится и «облако», а значит, все работавшие в нем ИТ-системы станут недоступны. Многие спрашивают у провайдера про внутренние средства обеспечения доступности облачной платформы. Это правильно, но этого недостаточно.
Так как некоторый тип данных по законодательству нельзя выносить за пределы РФ, выбор останавливается на «местных» ЦОД или находящихся в пределах страны.
Также стоит обратить внимание, находится ли ЦОД в собственности у провайдера или провайдер арендует его у своего партнера. В арендованной площадке нет ничего плохого. Вполне возможно, что в компании партнера работают высококлассные специалисты, которые способны действовать быстро и слаженно в любых ситуациях. Но все-таки при аренде площадки путь вашей заявки от момента отправки до начала работы инженера компании-собственника ЦОД получается несколько дольше. В этом случае облачный провайдер выступает в качестве передаточного звена, и схема работы получается менее гибкой и оперативной.
2. Облачная платформа
Процессорные мощности
На рынке существует несколько способов продажи процессорных мощностей:
· Продажа «расшаренных» ресурсов. Все, что сейчас свободно, может быть занято вашими серверами.
· Гарантированное выделение ресурсов.
Первый вариант, как правило, предлагается в красивой маркетинговой обертке. Вы можете сами выбрать нижнюю и верхнюю границы выделения вычислительных ресурсов. Нижняя граница будет выделена гарантированно, а ресурсы между нижней и верхней границами будут выделяться по требованию и оплачиваться по факту использования. Подход красивый. Но есть нюанс. Когда вам срочно понадобятся все доступные вашему виртуальному серверу ресурсы, далеко не факт, что их не используют ваши соседи по физическому серверу и что они смогут быть выделены. Второй вариант предоставления ресурсов менее гибкий в части оплаты, зато более стабильный в части выделения ресурсов и работы ваших систем. Использование того или иного подхода имеет ряд преимуществ и недостатков, которые могут быть выгодно использованы в той или иной ситуации. Оба подхода имеют право на жизнь.
Облачные провайдеры измеряют процессорную мощность своих серверов в vCPU. Вот возможные варианты расчета мощности vCPU:
· 0,4 – 1 ГГц частоты физического ядра процессора
· 1/3 или 1/4 физического ядра процессора
· 1 физическое ядро процессора
Мощность процессорных ядер с 2007 года увеличилась в 3,5 раза. Это можно заметить по доступным типам виртуальных серверов на Амазон. В 2007 году Амазон начал предоставлять облачные услуги, и для этого было закуплено оборудование. Тогда использовались процессоры Intel Celeron. Была замерена их производительность и взята в качестве эталона. Эталон был назван ECU (Elastic compute unit). Сейчас в Амазон можно заказать виртуальные серверы, мощность физических ядер которых равняется 3,5 ECU. Отсюда можно сделать вывод о росте мощности процессорных ядер за последние 6-7 лет в 3,5 раза.
Облачный провайдер под vCPU может подразумевать не физическое ядро, а его части, а еще может использовать старое «железо». Это означает, что vCPU у разных провайдеров может отличаться в 20-30 раз. Всегда нужно спрашивать, что такое vCPU, как vCPU соотносится с физическими ядрами и какие процессоры вообще используются.
Дисковое пространство
При выборе облачного провайдера стоит обратить внимание на дисковые ресурсы, которые предоставляются виртуальным машинам. В первую очередь, стоит спросить, как физически выглядит хранилище данных:
· Локальные диски на борту серверов
· Direct-attached полка с дисками
· Подключенная по SAN СХД
Первый и второй вариант чреваты потерей данных или долгой их недоступностью при выходе из строя сервера. Амазон, в частности, в качестве бонуса предоставляет заказчикам в рамках виртуальных машин дисковое пространство на локальных дисках. Выход из строя сервера чреват потерей всех данных.
Вторым ключевым моментом при рассмотрении дисковых ресурсов является гарантированный SLA в части IOPS, скорости чтения или записи данных. Гарантирует ли ваш провайдер определенную производительность СХД?
Подключение к облаку
Облачные провайдеры по умолчанию предоставляют услуги по доступу виртуальных серверов в Интернет. В первую очередь, нужно спросить, зарезервировано ли данное подключение? Используются ли разные провайдеры? Как производится переключение в случае отказа одного их каналов связи?
Вторым важным вопросом является то, умеет ли провайдер шэйпить полосу пропускания каналов связи до Интернет, то есть гарантировать определенную полосу пропускания.
Интеграция с «облаком». Гибридный режим работы
Скорее всего, когда вы задумаетесь переехать в «облако», вы сделаете это не в один момент. Будет длительные переходный процесс, когда вы будете жить и на локальной площадке, и в «облаке». В некоторых компаниях этот процесс может затянуться на год, а, возможно, и не завершится никогда.
В этом случае у провайдера важно спросить о механизмах интеграции вашей локальной ИТ-инфраструктуры с «облаком».
Если рассмотреть использование публичного «облака», то по умолчанию управление сетевыми настройками на стороне «облака» практически отсутствует:
· Вы не можете управлять внутренней адресацией. Если бы могли — случился бы коллапс.
· Вы не можете управлять маршрутизацией.
· Если рассматривать большинство российских провайдеров, то сети внутри «облака» построены на VLAN. Как правило, 1 заказчик = 1 VLAN. Все машины живут в одной сети. Далеко не у всех можно создавать дополнительные VLAN.
Управление сетями внутри «облака» далеко от того уровня гибкости и удобства, который доступен на собственной площадке. Про средства по сетевой интеграции и вовсе стоит забыть. От силы существует возможность построения VPN-туннеля между площадками. К счастью, существуют технические решения по реализации такого же удобного механизма работы с сетями в «облаке», как и на локальной площадке.
У провайдера нужно для начала спросить, имеется ли такая услуга в принципе. Если все-таки имеется, то можно задать дополнительные вопросы. Используется коммерческий продукт или Opensource? Если используется свободное ПО, то сразу стоит закладывать риски того, что поддержкой этого решения занимается сам провайдер, а не вендор.
Отсюда вытекает второй риск. Вендор комплектует свое ПО по резервному копированию всеми необходимыми агентами для консистентного бэкапа прикладного ПО. Вряд ли у вас получится забэкапить SAP с использованием Opensource решения по резервному копированию. У провайдера всегда нужно спросить список совместимости для данного решения по резервному копированию.
Важно уточнить у провайдера, на чем хранятся копии, на дисках или на ленте. Лента является более дешевым носителем информации, но риск не восстановиться гораздо выше. Более того, работа с лентой происходит медленнее, чем с дисковым носителем. Если информация хранится на дисках, а вам в качестве дополнительного сервиса нужно периодически переписывать копии на отторгаемые носители, то у провайдера нужно поинтересоваться о такой возможности.
Ну и наконец, важным моментом является тип предоставления услуги. Как ей можно управлять? Есть ли портал самообслуживания? Можно ли самому управлять расписанием по резервному копированию, бэкапить и ресторить данные без привлечения провайдера?