Проверил SAP HANA Hardware Directory. В разделе Certified IaaS Platforms среди амазонов, ажуров и прочей али-бабы LinxCloud не обнаружил. Так о какой именно сертификации речь?
Посчитал в вашем конфигураторе машинку: 32core+512gb ram + 1920gb ssd = 340K в месяц (вы это серьезно?)
dell r630 c такими же ресурсами идет за 1.5M, т.е. отбивается за 5 мес., а эксплуатироваться будет года 3 минимум.
Кстати, у DellEMC для DD VE есть готовые конфигурации на базе сервера R730 c локальными HDD. Выглядит интересно. Дюже любопытно было бы у видеть тест производительности по сравнению с железным DD в одинаковой конфигурации по дискам.
Есть еще IBM ProtectTIER, но он, похоже, «скорее мертв, чем жив». А виртуальной его версии IBM так и не сподобилась сделать.
Смущает во всей этой дедупликационной идеологии РК один момент (если я все правильно понимаю): получается, что мы целиком и полностью зависим от самого первого бекапа. Если его по какой-то причине профукали, то никаких бекапов по сути больше нет. Это так? Есть ли в таких дедупликаторах возможность делать независимые «настоящие» фулл-бекапы, скажем, по требованию?
А вариант отдельно стоящей и доступной по NFS СХД Netapp c инлайн-дедупом и компрессией стоит рассматривать как альтернативу DD/StoreOnce?
"После многочасовых попыток установить СУБД DB2 10.5 с помощью графической утилиты установки db2setup"
Что же Вы с ней такое делали? ;) Обычно минут 15 максимум (при соблюдении пререквизитов)
Это время включает в себя дедупликацию, сжатие и собственно передачу данных. Для shared системы резервного копирования — это приемлемая скорость. На выделенных решениях, например, кейс 2, скорость будет выше – до 3 Gb/s. Дедупликация на стороне клиента.
Ясно. Спасибо.
HANA работает на виртуальных машинах
А ваше облако каким-то образом сертифицировано SAP-ом под HANA (спрашиваю потому что обнаружить вас в списке SAP HANA Certified IaaS Platforms не удалось)?
Полный бэкап одной из баз данных объемом 181 ГБ делается за 1 час 54 минуты.
27 MB/s? Что- то совсем не быстро. Дедупликация где выполнялась? На HANA-хосте или медиа-агенте?
У клиента был большой объем исходных данных (почти 18 ТБ). Если складывать данные на ленточную библиотеку, как клиент это делал ранее, то потребовалось бы несколько десятков картриджей
Хм… на LTO-6 картридже с компрессией вполне себе лежат 4 бекапа 1.5TB базы.
Не совсем в тему вопрос: клиент хостит HANA'у на выделенных физ. машинах или на виртуалках?
У меня была виртуалка на 16vCPU на стареньком IBM x3850M2 (4 x 4 core Xeon X7350) + 60GB RAM.
LINEITEM и ORDERS были непартицированные с опцией COMPRESS FOR DIRECT_LOAD, загружены sqlldr'ом. Раздувал sga_target и прогонял запросы первым проходом, чтобы все таблицы закешировались. В последующие запуски смотрел nmon'ом, чтобы отсутствовал disk i/o.
Тоже гонял TPC-H (SF=50, таблица LINEITEM на 300M строк) на предмет сравнения отдельных запросов из буффер-кэша vs. инмемори-кэша. Из IMC получалось в среднем в 3 раза быстрее. Можете показать результат Q1 для обоих случаем с использованием /* parallel(4) */?
Технология особенно интересна своей гибкостью (возможностью грузить в IMC отдельные колонки/партиции), но стоит ли оно того чтобы платить +50% к процессорной лицензии на EE это «нужно посмотреть» в каждом отдельном случае.
По поводу результатов в бенчмарке SAP BW-EML: по-честному победить HANA'у не удалось, поэтому нагло читили с использованием матвьюшек, в результате закономерно не получили своего сертификата, что конечно же нисколько не мешает рассказывать «пастве» о том, как «мы порвали SAP на его же бенчмарке поэтому он наш результат не сертифицирует»
dell r630 c такими же ресурсами идет за 1.5M, т.е. отбивается за 5 мес., а эксплуатироваться будет года 3 минимум.
Кстати, у DellEMC для DD VE есть готовые конфигурации на базе сервера R730 c локальными HDD. Выглядит интересно. Дюже любопытно было бы у видеть тест производительности по сравнению с железным DD в одинаковой конфигурации по дискам.
Есть еще IBM ProtectTIER, но он, похоже, «скорее мертв, чем жив». А виртуальной его версии IBM так и не сподобилась сделать.
Смущает во всей этой дедупликационной идеологии РК один момент (если я все правильно понимаю): получается, что мы целиком и полностью зависим от самого первого бекапа. Если его по какой-то причине профукали, то никаких бекапов по сути больше нет. Это так? Есть ли в таких дедупликаторах возможность делать независимые «настоящие» фулл-бекапы, скажем, по требованию?
А вариант отдельно стоящей и доступной по NFS СХД Netapp c инлайн-дедупом и компрессией стоит рассматривать как альтернативу DD/StoreOnce?
"После многочасовых попыток установить СУБД DB2 10.5 с помощью графической утилиты установки db2setup"
Что же Вы с ней такое делали? ;) Обычно минут 15 максимум (при соблюдении пререквизитов)
Ясно. Спасибо.
А ваше облако каким-то образом сертифицировано SAP-ом под HANA (спрашиваю потому что обнаружить вас в списке SAP HANA Certified IaaS Platforms не удалось)?
27 MB/s? Что- то совсем не быстро. Дедупликация где выполнялась? На HANA-хосте или медиа-агенте?
Хм… на LTO-6 картридже с компрессией вполне себе лежат 4 бекапа 1.5TB базы.
Не совсем в тему вопрос: клиент хостит HANA'у на выделенных физ. машинах или на виртуалках?
Пост интересный. Спасибо.
У меня была виртуалка на 16vCPU на стареньком IBM x3850M2 (4 x 4 core Xeon X7350) + 60GB RAM.
LINEITEM и ORDERS были непартицированные с опцией COMPRESS FOR DIRECT_LOAD, загружены sqlldr'ом. Раздувал sga_target и прогонял запросы первым проходом, чтобы все таблицы закешировались. В последующие запуски смотрел nmon'ом, чтобы отсутствовал disk i/o.
Технология особенно интересна своей гибкостью (возможностью грузить в IMC отдельные колонки/партиции), но стоит ли оно того чтобы платить +50% к процессорной лицензии на EE это «нужно посмотреть» в каждом отдельном случае.
По поводу результатов в бенчмарке SAP BW-EML: по-честному победить HANA'у не удалось, поэтому нагло читили с использованием матвьюшек, в результате закономерно не получили своего сертификата, что конечно же нисколько не мешает рассказывать «пастве» о том, как «мы порвали SAP на его же бенчмарке поэтому он наш результат не сертифицирует»