По итогам рассмотрения документации по процедуре "Квалификационный отбор № 000" на ЭТП Фабрикант, по Платформе IT у нас появились следующие вопросы:
1. Есть ли у Вашей компании предпочтение в производителе оборудования в данном проекте? Просьба перечислить их. Нет. Более того, мы не ставим явное требование, что система должна быть конвергентной или гиперконвергентной. Ждем предложения от участника
2. В технических требованиях во втором разделе «2. Этапность внедрения платформы» среди перечня основных требований – «Иметь средства разработки дополнительных сервисов» и «Обеспечивать возможность интеграции с прочими ИТ-системами группы компаний. Иметь унифицированные API.», требования очень размытые и не несут никакой конкретики. Просьба пояснить развёрнуто. На 2 и 3 этапах, когда систему планируется использовать для предоставления клиентских сервисов, потребуется интеграция с нашими ИС (биллинг, мониторинг и др.). Сейчас нам важно понимать наличие потенциальной возможности это сделать, в том числе нашими силами, посредством API.
3. Из состава подсистем на первом этапе:
a. подсистему вычислительной инфраструктуры;
b. подсистему телекоммуникационной и коммутационной инфраструктуры;
c. подсистему хранения данных;
d. подсистему резервного копирования (опционально);
e. подсистему виртуализации;
f. подсистему управления и мониторинга;
g. подсистему оркестрации и провижининга;
h. подсистему централизованной авторизации.
Более-менее есть адекватные требования для «подсистемы вычислительной инфраструктуры», «подсистемы хранения данных». Они основные на первом этапе.
Есть куцые требования из одного двух пунктов для следующих подсистем: подсистема резервного копирования (опционально) (можно реализовывать в виде отдельной системы резервного копирования или на существующей платформе), подсистема виртуализации (жестких требований на систему виртуализации не накладывали. Но должна быть возможность перенести наши существующие сервисы с сохранением существующих вариантов гипервизоров или с миграцией на альтернативные), подсистема управления и мониторинга (должна быть. Выберем лучшее. Наша существующая общекорпоративная система Zabbix). У Вас есть к ним уточнения?
Нет требований на следующие подсистемы: подсистема телекоммуникационной и коммутационной инфраструктуры (без конкретики, рассматриваем различные варианты 100GE, FC и пр. Предлагайте…), подсистема оркестрации и провижининга, подсистема централизованной авторизации (тоже самое). Просьба предоставить.
4. Какой тип клиентов у заказчика, которым будут предоставляться облачные ресурсы? В основном B2B, B2О, GA, NA
5. В шестом разделе технических требований - 6. Функциональные требования к аппаратно-программному решению серверной платформы –приведена таблица, с пояснениями – «Формализованные требования, предъявляемые к функционалу серверной системы на различных этапах внедрения платформы». В таблице заполнены только названия компонентов, требований к этим компонентам и в соответствии с этапами нет. Поясните кто её должен заполнять? См. сам RFP, там требуемы функционал разбит по этапам.
6. В таблице функциональных требований есть пункт – «Шифрование данных при хранении (на уровне диска)», это требование в рамках российской действительности и российского законодательства не возможен. С какой целью этот пункт включен в требования? Интересует техническая возможность.
7. Требования к интеграции «облако-облако», нет конкретики, с каким «облаками» он должен интегрироваться, с какой целью? Точное КП на 1 этап, на 2-3 этапах интересует наличие возможности, оценочные стоимости.
8. В таблице функциональных требований есть две строки – «Бэкап как сервис» и «Резервное копирование как сервис», чем они отличаются? Резервное копирование как сервис на отдельной системе резервного копирования, во внешнем облаке. Бэкап на внедряемое хранилище. И для PaaS, и для SaaS. На первом этапе не предусмотрено.
В п.5 приводятся «Требования, предъявляемые к основным подсистемам платформы на первом этапе». Пункт 6 содержит незаполненную таблицу с функциональными требованиями к аппаратно-программному решению серверной платформы. Технических требований к аппаратно-программному комплексу второго и третьего этапа нет. Эти требования необходимы для корректной разработки таблицы, определенной на бланке ТКП – затраты по 3 этапам.
Без технических требований это сделать невозможно.
Причем в п.5. подчеркнуто, что приведены требования только для первого этапа.
Функциональные требования на всех этапах прописаны в самом RFP.
Первый этап – нужно точное КП. По 2-3 этапу подтверждение возможности, оценочные стоимости.
Нет информации о подключении к электропитанию – требуется ли дополнительная системы бесперебойного питания или есть возможность работы уже с существующей системой на площадках размещения оборудования.
Системы электроснабжения в случае размещения на наших площадках наши.
В случае размещения в комм. ЦОД – входят в стоимость размещения.
Отдельно закладывать не надо.
В п. 5.2. (последний подпункт) требуется обеспечить наличие в составе СХД ПО «с функциями балансировки, перераспределения данных и обновления хранилища без прерывания работы системы, автономного структурирования хранилища, динамического переноса данных и программное обеспечение по переносу данных между несколькими СХД». Необходимо понимать тип СХД, работа с которыми планируется.
СХД выбирается и поставляется в рамках тендера.
Дополнительно необходимо предусмотреть возможность интеграции с внешними облаками (Amazon и пр.)
Есть ли в существующем сетевом оборудовании порты для подключения 7-ми серверов, в каждом из которых используется по 2хRJ-45 1Gb и 2хRJ-45 10Gb интрфейсы?
Систему коммутации надо заложить в решение.
5• требуемый интегральный процессорный ресурс - не менее 650 ГГц;
• требуемый интегральный ресурс ОЗУ - не менее 3 Tбайт;
Термин «интегральный» имеет под собой ввиду суммарную мощность всех серверов? Да. На 1 этап.
Для «процессорного ресурса» учитывается гипертрединг? Тут указан требуемый ресурс с условным мультипликатором на рост. Считаем, что и HTT учтен. Опять же – на 1 этап. Далее массштабируемость.
Как в представлении художника Заказчика / Партнера выглядит архитектура решения?
Требований к архитектуре мы не предъявляем. Из RFP убрали даже упоминание о конвергентности/гиперконвергентности. Ждем предложений участников.
• требуемый размер кэш-памяти – не менее 32 Гбайт с возможностью расширения.
У нас такого понятия, как расширение кэш-памяти (НЕ флэш-кэш) нет
Какой финальный объем кэша планируется на СХД? Ко второму и третьему этапу точные требования мы не формировали. Но нужна высокая степень масштабируемости. Будем сравнивать предложения участников.
Есть ли требования к количеству контроллеров системы? Нет
5.1. Требования к вычислителям:
- требуемый интегральный процессорный ресурс - не менее 650 ГГц; требуемый интегральный ресурс ОЗУ - не менее 3 Tбайт;
Да, имеется в виду интегральный ресурс, требуемый нам на первом этапе.
Сверху – требуется условно неограниченная масштабируемость.
5.4.Требования к системе виртуализации:
- Наличие поддержки мультигипервизорности желательно.
Поддержка разных виртуализаций.
- Желательна поддержка контейнеризации.
Поддержка управления контейнерами с поддержкой оркестраторов.
Оба этих пункта желательны (!!!), не обязательны.
7
- Операционные системы: Linux, СentOS 5.X, 6.X и 7.X, MS Windows 2003 Server, Windows 7, 2008, 2008 R2, 2012, 2012 R2, 2016, MS Windows Server 2012, MikroTik RouterOS 5.XX и 6.XX, OS Linux Debian 7-9, Ubuntu 10.04-16.04, FreeBSD 10.
Да, это ОС, которые у нас есть сейчас на виртуальных машинах и мы хотим их перенести на единую платформу.
Комментарии от 19.04.18:
1. Модель лицензирования
Принимаете ли вы возможность использования модели лицензирования решения, базирующейся на количестве виртуальных машин (ВМ)? Это, возможно, будет экономически более целесообразно, учитывая, что у вас есть потребность в размещении ВМ, которые более требовательны к ресурсам (для которых требуются хосты с 4+ процессорами и хосты с частотой 3+ ГГц). В случае лицензирования по количеству ВМ такие виртуальные хосты будут равны с точки зрения лицензий «обычным» средним ВМ в облаке. Да, такая модель может быть рассмотрена. Но лучше лицензироваться по количеству физических процессоров (количеству физических серверов, находящихся в управлении системы виртуализации).
2. Поддерживаемые облачные сервисы
Вы перечислили IaaS, PaaS и SaaS как требуемые сервисы, предполагаемые к реализации в единой корпоративной серверной платформы. Какие именно сервисы данных типов предлагаемое решение должно поддерживать? На первом этапе – виртуальные машины для производственных и корпоративных систем. На 2-3 этапах – перечень в проработке.
3. Многоуровневое хранение
В пункте 5.2 вы указали, что емкость SSD накопителей должна быть не менее 20 % от емкости СХД. Как предполагается использовать емкость SSD накопителей – как единый пул с несколькими уровнями хранения SSD/HDD или как самостоятельный пул хранения только на SSD накопителях? Как единый пул с несколькими уровнями хранения.
4. Производительность СХД
В пункте 5.2 вы указали значение производительности СХД не менее 75000 IOPS. Для какого профиля нагрузки ввода/вывода должна обеспечиваться данная производительность? Данная производительность должна обеспечиваться только уровнем SSD накопителей или на всем суммарном объеме «гибридного» хранения (SSD+HDD)? Это средняя величина на все хранилище. Профиль нагрузки указан в RFP.
5. Миграция данных
В пункте 5.2 вы указали требование прозрачной (без остановки работы СХД) миграции данных. Какая миграция имеется в виду – между СХД в предложенном решении и некими сторонними существующими системами хранения или между разными уровнями (типами) хранения внутри предлагаемого облачного решения? Имеются ввиду оба типа миграции.
6. Пользовательские сервисы
В пункте 6 вы привели таблицу с формализованными требованиями. Какие из приведенных в таблице сервисов должны быть доступны тенантам (пользователям) для самостоятельного развертывания через портал самообслуживания? Перечень будет определен позже при открытии тендера на 2-3 этапы.
7. Бэкап как сервис
В пункте 6 вы привели таблицу с формализованными требованиями. В качестве требований в разделе SaaS/PaaS указаны «Бэкап как сервис» и «Резервное копирование как сервис». В чем различие в данных сервисах с точки зрения ваших требований?
Резервное копирование как сервис на отдельной системе резервного копирования или во внешнем облаке. Бэкап - на внедряемое хранилище. И для PaaS, и для SaaS. На первом этапе не предусмотрено.
8. Проектная документация
Необходимо ли предоставление в рамках выполнения работ проектной документации по стандартам ГОСТ или другим? Нет
9. Язык пользовательского интерфейса
Принимаете ли вы английский язык в качестве языка пользовательского интерфейса предлагаемого решения, включая портал самообслуживания пользователей (желательно наличие русского) и портал администраторов облака (английский)?
10. Типы облака на разных этапах
Что именно понимается под терминами Networks Cloud и Service Cloud? Является ли Networks Cloud в вашем понимании аналогом термина Private Cloud, то есть облака, развернутого внутри компании и используемого для внутренних нужд? Является ли Service Cloud в вашем понимании аналогом термина B2B Cloud, то есть облака, развернутого внутри компании и используемого для предоставления облачных ресурсов внешним заказчикам?
NC – облака для производственных нужд и нужд корпоративных ИТ, т. е. для внутреннего использования.
SC – облака, как услуга для вешних клиентов.
11. Поддержка ОС
Поддержка каких функций работы с ВМ на базе разных типов ОС (в частности, MikroTik RouterOS) требуется поддерживать? В частности, требуется ли поддерживать снепшоты ВМ, онлайн-миграцию ВМ, остановку/паузу ВМ, онлайн-добавление ресурсов (процессоры, память, диски, сетевые интерфейсы) для ВМ на базе этой ОС и других ОС из вашего списка? Или достаточно будет обеспечить корректную работу ВМ с данными ОС на облачных ресурсах? Планируется эксплуатация большого количества VM с MikroTik RouterOS. Снапшоты – желательны. Онлайн-миграция – одно из требований. Онлайн-изменение ресурсов: процессов – не требуется, ОЗУ – не требуется на 1 этапе, на 2-3 - желательно; сетевых интерфейсов – да; виртуальных дисков – желательно. На этапе внедрения NetworkCloud размещать на облачных (внешних) системах какие-либо VM не планируется, т. е. VM планируем разворачивать только с использованием собственных (внутренних) ресурсов.
12. Критерии выбора решения
В пункте 12 вы указали критерии выбора решения. В этом перечне не учитывается выполнение поставщиком необязательных требований (например, поддержка в решении разных гипервизоров). Будет ли учитываться выполнение необязательных требований при выборе поставщика решения? Если будет, то каким образом? Выполнение необязательных требований будет преимуществом при прочих равных условиях.
13. Резервирование компонентов
ТТХ, приведенные в RFP, указаны с учетом избыточности и резервирования, или же при расчете решения резервирование и избыточность следует заложить дополнительно к указанным вами требованиям? Запас по ресурсам учтен.
14. Количество ВМ
Можете ли вы предоставить информацию по максимальному количеству виртуальных машин, которые планируется запускать на указанных в RFP облачных ресурсах (650 ГГц процессорных ресурсов, 3 Тбайт памяти), и которые необходимо поддерживать в предлагаемом решении? Предоставим.
15. Сроки реализации
Можете ли вы предоставить информацию о предполагаемых датах реализации проекта? Какие ожидаемые сроки завершения внедрения каждого из этапов (или по крайней мере первого этапа)? Ориентировочные сроки первого этапа июль 2018-декабрь 2018 г. Оценочные сроки 2 и 3 этапа – 2019 г. и 2020 г., соответственно.
16. Разъяснение требуемого функционала
Просьба разъяснить (уточнить значение, которое имелось в виду) для следующего функционала/компонентов:
¦ Хранилище шаблонов / образов на первичном портале – что имеется в виду под «первичным» порталом? Портал администратора? Да, портал администратора.
¦ Максимальный размер хранилища на виртуальную машину – имеется в виду размер одного диска ВМ или суммарный объем всех дисков ВМ? «До 80% общей полезной емкости CХД» - это от 300 Тбайт или от какого-то другого объема? Здесь имеется ввиду практическое отсутствие ограничения на размер виртуальной дисковой подсистемы для VM.
¦ Взаимодействие СХД с внешними облачными сервисами – в чем должно заключаться такое взаимодействие? Имеется в виду непосредственно СХД, используемая в решении, или возможность выделения ресурсов хранения во внешних облаках? Возможность дополнения емкости СХД емкостями внешних облаков желательна.
¦ Архив / резервное копирование – должно поддерживаться что-то одно из этого или оба? Что имеется в виду под архивом? Архив ВМ? Резервное копирование.
¦ Поддержка собственного авторизационного центра для верификации сертификатов – какие сертификаты необходимо верифицировать и для кого этот сервис должен быть доступен? Для клиентских сервисов на 2-3 этапах.
¦ Максимальное количество VLANs на клиента – реализация именно 4096 VLAN для каждого клиента может быть затруднительна из-за наличия служебных VLAN. Возможно ли уменьшить требование до 4000 VLAN или до 4090 VLAN? Да, можно уменьшить количество. Имеется ввиду отсутствие принципиальных ограничений, т. е. значение равное 4096 минус небольшое количество служебных – подойдёт, например, 4000.
¦ Ограничение доступа пользователей по IP/диапазону и т. д. – имеется в виду ограничение на доступ к пользовательскому порталу или ограничение на сетевой доступ к ВМ? К пользовательскому порталу. Различная конфигурация фильтров для разных пользователей.
¦ Многоадресная рассылка на платформе – что имеется в виду под «рассылкой», broadcast или e-mail рассылка? Многоадресная рассылка уведомлений пользователям на 2-3 этапе (ЛК, е-mail)
¦ Интеграция (облако-облако и локальная среда-облако) – в чем должна заключаться интеграция? Расширение ресурсов за счет внешнего облака (ресурсы для VM, резервное копирование и пр.)
¦ Репликация (облако-облако и локальная среда-облако) – предполагается, что должна быть реализована репликация между облаками, а не только между локальной средой и облаком? Что имеется в виду под «локальной средой» - просто виртуализация на базе гипервизора? Для резервного копирования. С учетом наличия несколько площадок размещения инфраструктуры cистемы и возможной интеграции с несколькими внешними облаками.
¦ Механизм триггеров – для какого функционала необходим механизм триггеров? Какие действия необходимо поддерживать? Является ли это требование обязательным? Для всех ли гипервизоров оно обязательно? Триггеры на события. Перечень пока не определен. Желательно.
¦ Возможность реализации функционала учета превышения ресурсов (burst) – имеется в виду возможность выделения большего объема ресурсов, чем указано в квота для конкретного клиента, или что-то другое? Временное выделение и учет большего ресурса, чем указано в квоте. На 1 этапе не нужно.
¦ Миграция приложений – какая миграция должна поддерживаться? Между какими ресурсами? Миграция приложений на альтернативную VM для обеспечения непрерывности процесса предоставления пользовательских сервисов в случае аварийных ситуаций на текущей VM.
¦ Управление производительностью – какой производительностью необходимо будет управлять и в чем должно заключаться такое управление? Общее требование, возможно, пересекающееся с другими. Имеется ввиду: динамическое распределение ресурсов кластера между VM, автоматическая миграция VM между физическими серверами, при возникновении необходимости перераспределения нагрузки.
¦ Управление конфигурациями – что имеется в виду под «конфигурациями»? Конфигурации ВМ или что-то другое? Является ли это требование обязательным? Имеются ввиду: создание, применение, модификация, хранение, централизованный доступ для конфигураций VM.
¦ Управление активами программного обеспечения – что имеется в виду под «активами» ПО? Имеется в виду поддержка скриптов и пакетов для развертывания приложений внутри стандартных шаблонов ВМ? Да
17. Текущая ИТ-инфраструктура
Так как запрашивается сервис по миграции ВМ и приложений с существующей инфраструктуры, просьба предоставить информацию о том, какая инфраструктура сейчас используется в компании: количество и тип серверов, количество ВМ на каждом из типов гипервизоров, количество СХД и объем хранения данных на СХД. Также, поскольку ключевыми целями RFP является снижение затрат, просьба предоставить информацию о количестве сотрудников, занимающихся эксплуатацией и поддержкой указанной инфраструктуры. Предоставим о гипервизорах и VM на них. Остальное сможем предоставить после подписания NDA
