Комментарии 8
Похоже на советы «как сойти с ума при выборе облачного провайдера». И заодно свести с ума облачного провайдера.
Такой чек-лист актуален пожалуй только для опытного айтишника, который в курсе виртуализационных дел, ЦОДов и т.д. Т.е. для по настоящему крупного клиента. Не для SMB сектора.
«Выбор облачного провайдера — сложная задача.» — это действительно так. Но идёт в разрез с маркетинговым позиционированием массовых публичных облачных сервисов, где «облака — это легко и доступно».
Такой чек-лист актуален пожалуй только для опытного айтишника, который в курсе виртуализационных дел, ЦОДов и т.д. Т.е. для по настоящему крупного клиента. Не для SMB сектора.
«Выбор облачного провайдера — сложная задача.» — это действительно так. Но идёт в разрез с маркетинговым позиционированием массовых публичных облачных сервисов, где «облака — это легко и доступно».
По моему все правильно. Только вчера сдали пакет документов в ответ на тендер для облачной инфраструктуры. Клиент в своих запросах идет достаточно далеко (100 стр. тех. задания), к вышеуказанным требованием добавлю:
— интеграция его собств. датацентра и облака
— миграция в облако: методы, планировка
— как дать доступ партнерам к облаку по Интернет + ssl
— возможность виртуализации AIX
— можно ли иметь несколько зон в облаке
— патч-менеджмент опер. систем и ПО: какой процесс и периодичность
— может ли оператор разместить у себя в ДЦ особую аппаратуру клиента (riverbed, etc.)
— какие доп. средства может предоставить оператор (scheduler, cmdb, ...)
— а так же много запросов по поводу управления (все что относится к itilv3): роли, обязанности
В итоге такой чек-лист актуален, когда переноситься ИТ-инфраструктура в облако, а не просто два-три сервера.
— интеграция его собств. датацентра и облака
— миграция в облако: методы, планировка
— как дать доступ партнерам к облаку по Интернет + ssl
— возможность виртуализации AIX
— можно ли иметь несколько зон в облаке
— патч-менеджмент опер. систем и ПО: какой процесс и периодичность
— может ли оператор разместить у себя в ДЦ особую аппаратуру клиента (riverbed, etc.)
— какие доп. средства может предоставить оператор (scheduler, cmdb, ...)
— а так же много запросов по поводу управления (все что относится к itilv3): роли, обязанности
В итоге такой чек-лист актуален, когда переноситься ИТ-инфраструктура в облако, а не просто два-три сервера.
Вы абсолютно правы, такие вопросы нам тоже часто задают. Не стал их подробно рассматривать в посте, иначе бы его никто не осилил)
Вот что мы обычно в таких случаях отвечаем:
1. Интеграция облака с собственным ДЦ возможна, как на уровне платформы (построение горизонтальных распределенных L2 сетей, настройка динамической маршрутизации, настройка внутренней адресации в облаке), так и на уровне прикладного ПО.
2. По части миграции в облако крупных задач, мы стараемся организовать выделенного инженера, который помогает заказчику в планировании и проведении работ от начала и до конца.
3. Доступ к порталу самообслуживания, личному кабинету, а также к функциям управления виртуальной инфраструктурой через API защищаются SSL по умолчанию.
4. AIX машины можно всегда разместить рядом в ЦОД и интегрировать с виртуальными машинами облака.
5. У нас сейчас есть две зоны облака, представленные двумя удаленными дата-центрами.
6. Процесс обновления ОС и патч менежмент микрокодов инфраструктурных компонент облака происходит на периодической основе не реже чем раз в 2 неделе. О крупных обновлениях производится дополнительное уведомление заказчиков.
7. По части размещения дополнительного оборудования. Всегда пожалуйста. Также часто мы предлагаем заменить физическое оборудование его виртуальными аналогами, если такая возможность есть.
8. Мы предоставляем программные интерфейсы для доступа к управлению облачной инфраструктурой, поэтому наши клиенты могут самостоятельно реализовать любые требования в части дополнительных сервисов.
9. Поддержка ( + планирование, эксплуатация) всех наших заказчиков осуществляется по третьей редакции ITIL. Все эти процессы задокументированы и строго соблюдаются.
Вот что мы обычно в таких случаях отвечаем:
1. Интеграция облака с собственным ДЦ возможна, как на уровне платформы (построение горизонтальных распределенных L2 сетей, настройка динамической маршрутизации, настройка внутренней адресации в облаке), так и на уровне прикладного ПО.
2. По части миграции в облако крупных задач, мы стараемся организовать выделенного инженера, который помогает заказчику в планировании и проведении работ от начала и до конца.
3. Доступ к порталу самообслуживания, личному кабинету, а также к функциям управления виртуальной инфраструктурой через API защищаются SSL по умолчанию.
4. AIX машины можно всегда разместить рядом в ЦОД и интегрировать с виртуальными машинами облака.
5. У нас сейчас есть две зоны облака, представленные двумя удаленными дата-центрами.
6. Процесс обновления ОС и патч менежмент микрокодов инфраструктурных компонент облака происходит на периодической основе не реже чем раз в 2 неделе. О крупных обновлениях производится дополнительное уведомление заказчиков.
7. По части размещения дополнительного оборудования. Всегда пожалуйста. Также часто мы предлагаем заменить физическое оборудование его виртуальными аналогами, если такая возможность есть.
8. Мы предоставляем программные интерфейсы для доступа к управлению облачной инфраструктурой, поэтому наши клиенты могут самостоятельно реализовать любые требования в части дополнительных сервисов.
9. Поддержка ( + планирование, эксплуатация) всех наших заказчиков осуществляется по третьей редакции ITIL. Все эти процессы задокументированы и строго соблюдаются.
Вряд ли у вас получится забэкапить SAP с использованием Opensource решения по резервному копированию.
А в чём проблемы? Если вы этого не умеете, это не значит, что так никто не делает…
А в чём проблемы? Если вы этого не умеете, это не значит, что так никто не делает…
предположу, что компания которая инвестирует в сап, не поскупится купить проприетарное решение (emc networker, symantec nbu, etc) чтобы иметь гарантированный саппорт.
Вы не поверите, но существует большой класс компаний, которые именно на резервировании экономят.
К тому, же покупать из-за одного SAPa проприетарное решение на мой взгляд не самый лучший выбор.
В Sape и своих стандартных средств для резервирования хватает, на любой вкус и цвет…
К тому, же покупать из-за одного SAPa проприетарное решение на мой взгляд не самый лучший выбор.
В Sape и своих стандартных средств для резервирования хватает, на любой вкус и цвет…
Да, в сап есть стандартный набор утилит br*tools, который справляется с резервным копированием и достаточен. Но в итоге получается, что кроме сап, в инфраструктуре очень много всего что нужно сохранять — операционки, файлер, exchange какой-нибудь и т.д. И тут встает вопрос о том чтобы иметь единый софт, который бы имел необходимые модули для консистентого резервного копирования различного ПО, мог выдавать понятные отчеты, управлять каталогом копий и при этом имеющий саппорт.
Получается, что проще управлять всей этим через одно, пусть платное решение, чем несколько разрозненных утилит.
P.S. Если существует opensource решение отвечающее этим требованиям — тем лучше, правда я не знаю такое. Подскажите, возьму на заметку.
Получается, что проще управлять всей этим через одно, пусть платное решение, чем несколько разрозненных утилит.
P.S. Если существует opensource решение отвечающее этим требованиям — тем лучше, правда я не знаю такое. Подскажите, возьму на заметку.
Ещё могу порекомендовать сервис CloudHarmony. Там есть много информации по облачным хостингам, и что самое главное, сравнение различного типа инстансов на разных хостингах по разным видам бенчмарков. Там я узнал, что с точки зрения соотношения производительность/стоимость AWS — один из самых дорогих хостингов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практические советы по выбору облачного провайдера