olku, Да, конфликт пользователя и разработчика существует, но мы говорим не о нем. Мы говорим о другом конфликте, между программистом и администратором системы, которые работают вместе с пользователем в одной компании. Этот конфликт выгдялит так: программист написал код, который решает насущную проблему пользователя, а админ говорит: «У вас что ни новый релиз, так куча глюков, проблема мелкая, пусть пока потерпят со старой версией». Статья о том, что мы такой конфликт предлагаем решать через «бюджет простоев», а в качестве системы автоматизации предлагаем использовать ServiceNow и показываем, как система в этом контексте работает.
Конфликт между эксплуатацией и разработкой существует, и дабе такая компания как Google открыто признает, что там такая проблема есть.
LighteR, любая нода ES является координирущей. С текущей нагрузкой на мастер-ноды использовать выделенные координирующие ноды, на наш взгляд, нет необходимости.
kataklysm, не страшно, даже если ради него)). Резервное копирование мы делаем с помощью elasticdump. Данные планируем хранить глубиной на полгода, потом будем удалять раз в неделю на полгода + неделю, и хранить в архиве. Архивы – раз в неделю глубиной в неделю. (Храним данные в объектном хранилище, о котором писали в предыдущих постах).
cooper051, да, конечно, мы рассматривали и сравнивали разные системы — и IBM QRadar, и Solarwinds, Splunk, HP ArcSight. В нашем случае (для наших задач) ELK оказался максимально функциональным и соответствующим требованиям к стоимости. При этом мы не рассматриваем ELK как полноценную замену SIEM и сами в перспективе планируем запускать SOС. В данном примере ELK это именно система управления логами.
Hardened, ELK – это инструмент для сбора, хранения и просмотра логов платформы Техносерв Cloud, а значит, и нашего облачного хранилища. Внедрение централизованной системы хранения логов позволило сократить время на диагностику проблем в случае их возникновения.
speshuric, прежде чем ответить, хотим вас поблагодарить (кажется, мы этого еще не делали) за то, что потратили столько времени на анализ нашего поста и вообще на нас. Это очень полезная для нас критика и важное внимание. Мы постарались ответить на основные, на наш взгляд, поставленные вами вопросы. Как вы делите диски (с учетом того, что они виртуальные)?
Ограничиваем производительность дисков, управляя SLA на уровне СХД. Используете ли thin pools/LUNs и т.п.? Если да, то как боретесь с latency LDF, сколько она сейчас у вас в миллисекундах? Если нет, то как вы управляетесь с сотнями LUN хитро разбитыми по задачам и как обеспечиваете отсутствие взаимного влияния инстансов ВМ? Какие носители для какой нагрузки используете?
Нет, не используем. Для баз данных наших заказчиков мы используем производительную систему хранения данных Dell SC9000 c полками Dell SC420 на SSD дисках. Как и где хрянятся бэкапы, как обеспечиваете RPO/RTO без влияния на производительность?
Бекапы хранятся на выделенной СХД. Базы данных и логи баз данных хранятся на другой выделенной СХД. Как обеспечиваете HADR с точки зрения производительности? Это совсем не просто. Что в ваших терминах значат «Отказоустойчивая база данных», «База данных повышенной доступности», «Кластерное решение»?
Ответим на примере MS SQL
Отказоустойчивая база данных
Предоставляется одна система с необходимыми характеристиками. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
База данных повышенной доступности (Always On Availability Groups)
Предоставляется две системы с необходимыми характеристиками. На одной из машин располагается основной экземпляр, на второй располагается резервный. В случае выхода из строя основной базы данных происходит переключение на резервную базу данных. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
Гео-кластерное решение (Failover Clustering и Always On Availability Groups). Данная опция в разработке. Плановый срок ноябрь 2017г.
Предоставляется три выделенных системы с необходимыми характеристиками. Две машины объединяются в кластер и обслуживают работу с основной базой данных. Третья машина работает с резервной базой данных. В случае выхода из строя одного из узлов кластера, сервис поднимается на втором узле. В случае выхода из строя основной базы данных происходит переключение на резервную. Сервис остаётся доступным в случае выхода из строя любого из трёх хостов. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Используете ли Lock pages in memory (если да, то страдает гипервизор, если нет, то страдает БД)?
Для не misson-critical БД — нет, не используем. Нет, БД не страдает. Для mission-critical БД – да, используем. При этом обязательно выставляем соответствующий параметр max SQL server memory (как и для не mission-critical баз) и, соответственно, настраиваем гипервизор, чтобы не страдал :). Как с вашими планами обслуживания (перестроение индексов, DBCC CHECKs) вы обеспечиваете 99,95% (это 4 часа недоступности в год). Или вы считаете, что если инстанс пингуется, но таблица в 100 ГБ ребилдит индексы не online, то это тоже доступность?
Для расчета доступности сервиса используются данные системы мониторинга, контролирующей доступность каждого из нижеприведенных компонентов сервиса: хоста, базы данных, процессов прослушивания (Listener).
Поэтому, да, если инстанс пингуется, то это доступность сервиса.
При приходе нового заказчика мы выясняем его бизнес процессы, окна простоя и деградации производительности и настраиваем планы обслуживания в соответствии с бизнес ожиданиями заказчика.
Естественно никто не будет ребилдить индексы бездумно. У нас есть пример ребилда 2 терабайтных индексов, и на это отводится время раз в месяц в соответствии с договоренностями с бизнес подразделениями Заказчика.
Если же клиент ощутит нехватку производительности при плановых работах, то заводится инцидент и по нему начинается анализ.
Если выяснится, что влияет именно DBCC CHECKDB, то возможны варианты развития событий, например, вынести CHECKDB на вторичную реплику в AAG; вынести CHECKDB на систему восстановленную из бекапа, делать CHECKDB не регулярно.
Мы как DBA предлагаем наиболее приемлемый вариант из Best practices с описанием всех достоинств и недостатков, а клиент выбирает подходящий ему вариант. У вас не так много видов ВМ, всего 5 (по vCPU/vRAM) — какая стандартная настройка предела памяти для каждого вида и сколько файлов tempdb, какой MaxDOP по каждому варианту?
*Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок – возможно увеличение.
** Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок при использовании SQL server 2016 – возможно увеличение.
speshuric, рекомендуемые нами настройки как для «облачных», так и для «не-облачных» баз обычно совпадают (применительно к MS SQL Server), исключения могут составлять сервисы вида AWS RDS, где очень урезаны возможности конечного пользователя относительно настроек SQL сервера. В статье мы рассказали не только о том, как мы инсталлируем SQL server, но и как оптимально его настраиваем и поддерживаем в соответствии с потребностями заказчика.
Нашей целью было коротко пройтись по «узким местам» настройки SQL Server и указать на наиболее оптимальные настройки и механизмы обеспечения производительности. Если начать писать о том, как все настраивать, то объем статьи легко вырастет до “SQL Server Books Online". Кроме того, для основной части настроек существуют только общие рекомендации, причем зачастую нет официальных данных от Microsoft, и для каждого конкретного случая надо принимать свои решения.
Нам кажется, что имеет смысл написать отдельные статьи на очень многие вопросы, которые вы затронули. Что скажете?
astono0,bluetooth, попробуем ответить вам по порядку: 1. Максимально неудобный и неинтуитивный интерфейс. Чтобы с ним разобраться, существует целый 4 часовой тренинг. Количество менюшек на экране просто зашкаливает, хотя нужны из них хорошо если 20%
Количество полей, видимых пользователю, легко настраивается. Вероятно, администратор системы счел все их необходимыми для пользователя. 2. Почти любое действие вызывает перезагрузку страницы (выбрал отдел, выбрал сотрудника, поменял тип задачи etc)
В версиях Стамбул и Хельсинки мы у себя и своих заказчиков не наблюдали таких явлений. Возможно, это более старая версия? mtolstov, вы с чем-то подобным сталкивались? 3. Переход между страницами от 3-5 секунд, а в сочетании со вторым пунктом это превращает даже самую простую задачу в чудовищную трату времени.
Это вопрос ресурсов, на которых система размещена. Видимо, мощностей недостаточно для быстрой работы. Наши пользователи не жалуются :) 4. Отображение информации абсолютно не адаптировано для хоть немного удобного восприятия.
Отчасти повторим свой комментарий по первому пункту: почти всё в системе настраивается так, как это необходимо пользователю. В статье приведены скриншоты системы, разве они неудобны для восприятия?
Да, запутаться тут можно из-за многообразия конфигураций. Попробуем объяснить. S3 тут не воспринимается как блочное устройство. Оно является внешним хранилищем к которому обращаются по S3 с запросами по размещению или получению объекта, прощу файла. CV Simpana в своем функционала имеет возможность дедупликации и компрессии на программном уровне. Проще говоря, это происходит так. На серверах СРК хранится БД дедупликации, в которой хранится информация какие блоки есть в системе. Когда производится РК ПО Simpana проверяет весь поток данных на нахождение аналогичных блоков в системе и на повторяемость блоков в рамках потока. Все повторяющие блоки исключаются, вернее заменяются на ссылки на уже существующие в системе. Таким образом, поток дедуплицируется. Уже дедуплицированный поток формируется в специальные контейнеры, фактически файлы содержащие новые уникальные блоки данных и дополнительную мету информацию. Как раз такие контейнеры отправляются в хранилище S3. Весть этот процесс происходит inline, т.е. «на лету» в ОЗУ сервера и не требует промежуточного хранилища для размещения недедуплицированных данных или проведения дедупликации на блочном устройстве.
CV Simpana довольно гибкий продукт, в нем можно сразу «лить» резервные копии на S3 хранилище, либо сначала делать копии на локальные блочные хранилища, Ю а потом по специальному рассписанию переносить в S3 хранилище и множество других комбинаций.
Предугадывая логичный вопрос — БД дедупликации не слияет на сохранность дедуплицированных данных. Даже если она будет потеряно (преднамеряно или по аварии), восстановление данных из дедуплицированного виде возможна без нее, т.к. вся необходимая мета информация для восстановления хранится в контейнерах. БД дедупликации нужна для оперативного процесса дедупликации, как раз из-за нее и возможно проведения процесса «на лету».
Dmitry88, Commvault Simpana имеет несколько вариантов лицензирования вплоть до подписки на определенное время (месяц, полгода, год и т.д).
Некоторое время назад (года 3-4 назад) наиболее востребованным способом было лицензирование по агентам, т.е. на каждый компонент приобреталась отдельная лицензия. В данном случае хранилище лицензировалось либо по объему, либо по количеству слотов (для устройств с возможностью отчуждения накопителей, например, ленточных библиотек).
В данный момент распространены и применяются в основном типы лицензирования основанные на FE (Front End) метриках, т.е. на исходных «данных».
Такими «данными» могут являться объем либо количество процессов в серверах \ пользователей \ почтовых ящиков и т.д.
А в данных политиках не лицензируется конечный объем хранимых копий.
К примеру, в компании есть 10ТБ данных, покупается лицензия CV Simpana на 10 ТБ исходных данных, и компания может хранить хоть 5, хоть 50 копий, главное чтобы у него хватило аппаратных ресурсов на это.
Конечно, есть еще и разные типы таких объемных лицензий, но общий подход описан выше.
В случае с CV Simpana, подключение к S3 хранилищам не производится на уровне ОС и не формируется некий псевдодевайс /dev/ S3, подключение формируется и управляется из самой системы РК. Это позволяет ПО Simpana самой управлять потоками и какие данные на него пойду. Если говорить об дедупликации, то она производится на программном уровне СРК и в хранилище уже направляются дедуплицированные данные.
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
Данный расчет ориентировочный и является предварительной оценкой, так как в каждом отдельном случае требуется произвести отдельный анализ и расчет или опытное тестирование.
Вообще, мы обычно рекомендуем делить полные копии по сегментам, чтобы поделить нагрузку и трафик по дням недели. К примеру, часть систем делают полное РК в понедельник, другие во вторник и т.д. Этот подход позволяет значительно снизить нагрузку к каналам.
SVVer, спасибо за комментарий! Приятно видеть, что наш материал вас заинтересовал! Отвечаем на ваш вопрос. Как и описано выше, при размещении ИС клиента в облаке Техносерв Cloud обе стороны обязательно составляют полный реестр требований по информационной безопасности (ИБ) и разграничивают зоны ответственности. Наша компания ответственна за защиту периметра от внешних угроз (межсетевое экранирование, защита от сетевых атак) и за защиту виртуальной инфраструктуры, а клиент ответственен за обеспечение ИБ внутри предоставленных ему провайдером виртуальных машин.
Таким образом, «Техносерв» в рамках предоставления услуги размещения ИС в сегменте «Закрытый» не занимается сертификацией ПО, а предоставляет аттестованную по требованиям защиты информации инфраструктуру.
Необходимость сертификации ПО из приведенного вами примера зависит от конкретного случая. Важно понимать функционал данного ПО: реализует ли оно какие-либо механизмы защиты, какие именно, применяются ли клиентами наложенные СЗИ, какие функции они выполняют и являются ли сертифицированными.
Что касается рабочих мест удаленных пользователей и разработчиков, это в зоне ответственности клиента. При этом, мы предоставляем защищенный удаленный доступ посредством ГОСТ VPN. Выбор технических и программных средств, которые организуют защищенное соединение, зависит от предпочтений клиента.
По поводу бумаг для государственных информационных систем — аттестация. Для ИСПДн — либо аттестация ИСПДн, либо экспертное заключение, которое выдается после подтверждения того, что клиент выполняет все предъявляемые к нему требования по защите.
kataklysm, спасибо за интересный вопрос! Чтобы на него ответить, пришлось немного покопаться в документах (здесь и здесь). Вот что выяснилось: в Rados GW не поддерживаются Response Headers: Server, x-amz-delete-marker, x-amz-version-id. Есть также операции, явно заявленные как «неподдерживаемые»: GET Bucket policy, PUT Bucket policy, DELETE Bucket policy. Нашли операции, для которых поддержка не заявлена в принципе: GET Bucket logging, PUT Bucket logging, GET bucket replication, PUT bucket replication, DELETE bucket replication, GET Bucket tagging, PUT Bucket tagging, DELETE Bucket tagging, OPTIONS object, POST Object restore, GET Bucket cors, PUT Bucket cors, DELETE Bucket cors.
Все перечисленные команды и операции поддерживаются нашим хранилищем.
Если найдете неточности или захотите добавить в список что-то, что из S3 недостаточно хорошо поддерживается в RGW, дайте, пожалуйста, знать – мы будем благодарны за корректировки.
Конфликт между эксплуатацией и разработкой существует, и дабе такая компания как Google открыто признает, что там такая проблема есть.
Как вы делите диски (с учетом того, что они виртуальные)?
Ограничиваем производительность дисков, управляя SLA на уровне СХД.
Используете ли thin pools/LUNs и т.п.? Если да, то как боретесь с latency LDF, сколько она сейчас у вас в миллисекундах? Если нет, то как вы управляетесь с сотнями LUN хитро разбитыми по задачам и как обеспечиваете отсутствие взаимного влияния инстансов ВМ? Какие носители для какой нагрузки используете?
Нет, не используем. Для баз данных наших заказчиков мы используем производительную систему хранения данных Dell SC9000 c полками Dell SC420 на SSD дисках.
Как и где хрянятся бэкапы, как обеспечиваете RPO/RTO без влияния на производительность?
Бекапы хранятся на выделенной СХД. Базы данных и логи баз данных хранятся на другой выделенной СХД.
Как обеспечиваете HADR с точки зрения производительности? Это совсем не просто. Что в ваших терминах значат «Отказоустойчивая база данных», «База данных повышенной доступности», «Кластерное решение»?
Ответим на примере MS SQL
Отказоустойчивая база данных
Предоставляется одна система с необходимыми характеристиками. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
База данных повышенной доступности (Always On Availability Groups)
Предоставляется две системы с необходимыми характеристиками. На одной из машин располагается основной экземпляр, на второй располагается резервный. В случае выхода из строя основной базы данных происходит переключение на резервную базу данных. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час). Время восстановления сервиса в случае потери базы данных зависит от объёма базы данных и интенсивности её использования. В случае аппаратного сбоя наша система автоматически обеспечит замену системы в течение нескольких минут.
Гео-кластерное решение (Failover Clustering и Always On Availability Groups). Данная опция в разработке. Плановый срок ноябрь 2017г.
Предоставляется три выделенных системы с необходимыми характеристиками. Две машины объединяются в кластер и обслуживают работу с основной базой данных. Третья машина работает с резервной базой данных. В случае выхода из строя одного из узлов кластера, сервис поднимается на втором узле. В случае выхода из строя основной базы данных происходит переключение на резервную. Сервис остаётся доступным в случае выхода из строя любого из трёх хостов. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой резервного копирования Commvault для надёжного и долговременного хранения. Резервируются файлы базы данных и журналы транзакций, которые сохраняются в течение 7 дней. В течение этого периода можно восстановить состояние базы данных по состоянию на момент последнего резервирования журнальных файлов (производится каждый час).
Используете ли Lock pages in memory (если да, то страдает гипервизор, если нет, то страдает БД)?
Для не misson-critical БД — нет, не используем. Нет, БД не страдает. Для mission-critical БД – да, используем. При этом обязательно выставляем соответствующий параметр max SQL server memory (как и для не mission-critical баз) и, соответственно, настраиваем гипервизор, чтобы не страдал :).
Как с вашими планами обслуживания (перестроение индексов, DBCC CHECKs) вы обеспечиваете 99,95% (это 4 часа недоступности в год). Или вы считаете, что если инстанс пингуется, но таблица в 100 ГБ ребилдит индексы не online, то это тоже доступность?
Для расчета доступности сервиса используются данные системы мониторинга, контролирующей доступность каждого из нижеприведенных компонентов сервиса: хоста, базы данных, процессов прослушивания (Listener).
Поэтому, да, если инстанс пингуется, то это доступность сервиса.
При приходе нового заказчика мы выясняем его бизнес процессы, окна простоя и деградации производительности и настраиваем планы обслуживания в соответствии с бизнес ожиданиями заказчика.
Естественно никто не будет ребилдить индексы бездумно. У нас есть пример ребилда 2 терабайтных индексов, и на это отводится время раз в месяц в соответствии с договоренностями с бизнес подразделениями Заказчика.
Если же клиент ощутит нехватку производительности при плановых работах, то заводится инцидент и по нему начинается анализ.
Если выяснится, что влияет именно DBCC CHECKDB, то возможны варианты развития событий, например, вынести CHECKDB на вторичную реплику в AAG; вынести CHECKDB на систему восстановленную из бекапа, делать CHECKDB не регулярно.
Мы как DBA предлагаем наиболее приемлемый вариант из Best practices с описанием всех достоинств и недостатков, а клиент выбирает подходящий ему вариант.
У вас не так много видов ВМ, всего 5 (по vCPU/vRAM) — какая стандартная настройка предела памяти для каждого вида и сколько файлов tempdb, какой MaxDOP по каждому варианту?
*Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок – возможно увеличение.
** Для типовой нагрузки со стороны приложения. В случае кастомных нагрузок при использовании SQL server 2016 – возможно увеличение.
Нашей целью было коротко пройтись по «узким местам» настройки SQL Server и указать на наиболее оптимальные настройки и механизмы обеспечения производительности. Если начать писать о том, как все настраивать, то объем статьи легко вырастет до “SQL Server Books Online". Кроме того, для основной части настроек существуют только общие рекомендации, причем зачастую нет официальных данных от Microsoft, и для каждого конкретного случая надо принимать свои решения.
Нам кажется, что имеет смысл написать отдельные статьи на очень многие вопросы, которые вы затронули. Что скажете?
1. Максимально неудобный и неинтуитивный интерфейс. Чтобы с ним разобраться, существует целый 4 часовой тренинг. Количество менюшек на экране просто зашкаливает, хотя нужны из них хорошо если 20%
Количество полей, видимых пользователю, легко настраивается. Вероятно, администратор системы счел все их необходимыми для пользователя.
2. Почти любое действие вызывает перезагрузку страницы (выбрал отдел, выбрал сотрудника, поменял тип задачи etc)
В версиях Стамбул и Хельсинки мы у себя и своих заказчиков не наблюдали таких явлений. Возможно, это более старая версия? mtolstov, вы с чем-то подобным сталкивались?
3. Переход между страницами от 3-5 секунд, а в сочетании со вторым пунктом это превращает даже самую простую задачу в чудовищную трату времени.
Это вопрос ресурсов, на которых система размещена. Видимо, мощностей недостаточно для быстрой работы. Наши пользователи не жалуются :)
4. Отображение информации абсолютно не адаптировано для хоть немного удобного восприятия.
Отчасти повторим свой комментарий по первому пункту: почти всё в системе настраивается так, как это необходимо пользователю. В статье приведены скриншоты системы, разве они неудобны для восприятия?
CV Simpana довольно гибкий продукт, в нем можно сразу «лить» резервные копии на S3 хранилище, либо сначала делать копии на локальные блочные хранилища, Ю а потом по специальному рассписанию переносить в S3 хранилище и множество других комбинаций.
Предугадывая логичный вопрос — БД дедупликации не слияет на сохранность дедуплицированных данных. Даже если она будет потеряно (преднамеряно или по аварии), восстановление данных из дедуплицированного виде возможна без нее, т.к. вся необходимая мета информация для восстановления хранится в контейнерах. БД дедупликации нужна для оперативного процесса дедупликации, как раз из-за нее и возможно проведения процесса «на лету».
Некоторое время назад (года 3-4 назад) наиболее востребованным способом было лицензирование по агентам, т.е. на каждый компонент приобреталась отдельная лицензия. В данном случае хранилище лицензировалось либо по объему, либо по количеству слотов (для устройств с возможностью отчуждения накопителей, например, ленточных библиотек).
В данный момент распространены и применяются в основном типы лицензирования основанные на FE (Front End) метриках, т.е. на исходных «данных».
Такими «данными» могут являться объем либо количество процессов в серверах \ пользователей \ почтовых ящиков и т.д.
А в данных политиках не лицензируется конечный объем хранимых копий.
К примеру, в компании есть 10ТБ данных, покупается лицензия CV Simpana на 10 ТБ исходных данных, и компания может хранить хоть 5, хоть 50 копий, главное чтобы у него хватило аппаратных ресурсов на это.
Конечно, есть еще и разные типы таких объемных лицензий, но общий подход описан выше.
В случае с CV Simpana, подключение к S3 хранилищам не производится на уровне ОС и не формируется некий псевдодевайс /dev/ S3, подключение формируется и управляется из самой системы РК. Это позволяет ПО Simpana самой управлять потоками и какие данные на него пойду. Если говорить об дедупликации, то она производится на программном уровне СРК и в хранилище уже направляются дедуплицированные данные.
Основными являются степень компрессии и дедупликации и скорость конечного 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
Данный расчет ориентировочный и является предварительной оценкой, так как в каждом отдельном случае требуется произвести отдельный анализ и расчет или опытное тестирование.
Вообще, мы обычно рекомендуем делить полные копии по сегментам, чтобы поделить нагрузку и трафик по дням недели. К примеру, часть систем делают полное РК в понедельник, другие во вторник и т.д. Этот подход позволяет значительно снизить нагрузку к каналам.
Таким образом, «Техносерв» в рамках предоставления услуги размещения ИС в сегменте «Закрытый» не занимается сертификацией ПО, а предоставляет аттестованную по требованиям защиты информации инфраструктуру.
Необходимость сертификации ПО из приведенного вами примера зависит от конкретного случая. Важно понимать функционал данного ПО: реализует ли оно какие-либо механизмы защиты, какие именно, применяются ли клиентами наложенные СЗИ, какие функции они выполняют и являются ли сертифицированными.
Что касается рабочих мест удаленных пользователей и разработчиков, это в зоне ответственности клиента. При этом, мы предоставляем защищенный удаленный доступ посредством ГОСТ VPN. Выбор технических и программных средств, которые организуют защищенное соединение, зависит от предпочтений клиента.
По поводу бумаг для государственных информационных систем — аттестация. Для ИСПДн — либо аттестация ИСПДн, либо экспертное заключение, которое выдается после подтверждения того, что клиент выполняет все предъявляемые к нему требования по защите.
Все перечисленные команды и операции поддерживаются нашим хранилищем.
Если найдете неточности или захотите добавить в список что-то, что из S3 недостаточно хорошо поддерживается в RGW, дайте, пожалуйста, знать – мы будем благодарны за корректировки.