Pull to refresh

Comments 7

UFO just landed and posted this here
Dmitry88, расчет канала каждый раз проводится индивидуально, так как зависит от нескольких факторов.
Основными являются степень компрессии и дедупликации и скорость конечного S3 хранилища.
Объектное хранилище Техносерв Cloud является горизонтально масштабируемым и на текущий момент имеет возможность гарантированной обработки до 10 Gbps суммарного потока и возможность его увеличения. В связи с этим конечное устройство не будет являться ограничением.
Степень дедупликации и компрессии всегда разное и имеет прямую зависимость от типа и структуры данных. Поскольку мы рассматриваем объем в 1-2 ТБ то можем предположить, что данные будут разнородными (с разной степенью эффективности компрессии и дедупликации). По нашему опыту (в рамках СРК Техносерв Cloud и локальных инсталляций наших заказчиков), первичная степень (первая полная копия) в среднем равна 2,5 (100% данных дедуплицируется в 40% конечного объема копий), вторичная степень (вторая и последующие полные копии) в среднем равны 5 (100% данных дедуплицируется в 40% конечного объема копий) при условии изменений с момента предыдущего полного РК не более 40-45%.
Предположим, что окно резервного копирования составляет 8 часов.
Таким образом, расчет требуемого канала будет следующим:
2 ТБ первая полная копия:
(2048*0,4)/(8*60*60)*8*1024 что равно ~233 Mbps
1 ТБ первая полная копия:
(1024*0,4)/(8*60*60)*8*1024 что равно ~116,5 Mbps
2 ТБ последующие полные копии:
(2048*0,2)/(8*60*60)*8*1024 что равно ~116,5 Mbps
1 ТБ последующие полные копии:
(1024*0,2)/(8*60*60)*8*1024 что равно ~58,25 Mbps
Данный расчет ориентировочный и является предварительной оценкой, так как в каждом отдельном случае требуется произвести отдельный анализ и расчет или опытное тестирование.
Вообще, мы обычно рекомендуем делить полные копии по сегментам, чтобы поделить нагрузку и трафик по дням недели. К примеру, часть систем делают полное РК в понедельник, другие во вторник и т.д. Этот подход позволяет значительно снизить нагрузку к каналам.
UFO just landed and posted this here
Dmitry88, Commvault Simpana имеет несколько вариантов лицензирования вплоть до подписки на определенное время (месяц, полгода, год и т.д).
Некоторое время назад (года 3-4 назад) наиболее востребованным способом было лицензирование по агентам, т.е. на каждый компонент приобреталась отдельная лицензия. В данном случае хранилище лицензировалось либо по объему, либо по количеству слотов (для устройств с возможностью отчуждения накопителей, например, ленточных библиотек).
В данный момент распространены и применяются в основном типы лицензирования основанные на FE (Front End) метриках, т.е. на исходных «данных».
Такими «данными» могут являться объем либо количество процессов в серверах \ пользователей \ почтовых ящиков и т.д.
А в данных политиках не лицензируется конечный объем хранимых копий.
К примеру, в компании есть 10ТБ данных, покупается лицензия CV Simpana на 10 ТБ исходных данных, и компания может хранить хоть 5, хоть 50 копий, главное чтобы у него хватило аппаратных ресурсов на это.
Конечно, есть еще и разные типы таких объемных лицензий, но общий подход описан выше.

В случае с CV Simpana, подключение к S3 хранилищам не производится на уровне ОС и не формируется некий псевдодевайс /dev/ S3, подключение формируется и управляется из самой системы РК. Это позволяет ПО Simpana самой управлять потоками и какие данные на него пойду. Если говорить об дедупликации, то она производится на программном уровне СРК и в хранилище уже направляются дедуплицированные данные.
UFO just landed and posted this here
Дмитрий, добрый день!
Если Вас заинтересовала данная услуга, можем предоставить на тестирование, напишите мне на почту avkuznetsov@technoserv.com.
Александр.
Да, запутаться тут можно из-за многообразия конфигураций. Попробуем объяснить. S3 тут не воспринимается как блочное устройство. Оно является внешним хранилищем к которому обращаются по S3 с запросами по размещению или получению объекта, прощу файла. CV Simpana в своем функционала имеет возможность дедупликации и компрессии на программном уровне. Проще говоря, это происходит так. На серверах СРК хранится БД дедупликации, в которой хранится информация какие блоки есть в системе. Когда производится РК ПО Simpana проверяет весь поток данных на нахождение аналогичных блоков в системе и на повторяемость блоков в рамках потока. Все повторяющие блоки исключаются, вернее заменяются на ссылки на уже существующие в системе. Таким образом, поток дедуплицируется. Уже дедуплицированный поток формируется в специальные контейнеры, фактически файлы содержащие новые уникальные блоки данных и дополнительную мету информацию. Как раз такие контейнеры отправляются в хранилище S3. Весть этот процесс происходит inline, т.е. «на лету» в ОЗУ сервера и не требует промежуточного хранилища для размещения недедуплицированных данных или проведения дедупликации на блочном устройстве.
CV Simpana довольно гибкий продукт, в нем можно сразу «лить» резервные копии на S3 хранилище, либо сначала делать копии на локальные блочные хранилища, Ю а потом по специальному рассписанию переносить в S3 хранилище и множество других комбинаций.
Предугадывая логичный вопрос — БД дедупликации не слияет на сохранность дедуплицированных данных. Даже если она будет потеряно (преднамеряно или по аварии), восстановление данных из дедуплицированного виде возможна без нее, т.к. вся необходимая мета информация для восстановления хранится в контейнерах. БД дедупликации нужна для оперативного процесса дедупликации, как раз из-за нее и возможно проведения процесса «на лету».
Sign up to leave a comment.