Произошла по истине великая миграция СУБД. Это одна из самых драматичных глав трансформации.
Ох уж эти сказочники-импортозаместители....Произошла она (но это не точно) в основном в госухе (которая денег не считает) и по понятными причинам. Коммерсы за редким исключением продолжают сидеть на "Oracle, Microsoft SQL Server и DB2" ибопривозить себе собственными руками и за свой счет геморой на голову проблемы с давно и нормально работающими системами дураков желающих не особо много. А самое главное "чтобы что?"
Открытая СУБД PostgreSQL из «одной из опций» превратилась в стратегический стандарт.
Как говорится "на безрыбье и рак рыба"
Её российские форки (Postgres Pro) предложили дополнительные функции и коммерческую поддержку, что было важно для крупных предприятий.
Еще бы ценник адекватный они предложили за свои "дополнительные функции и коммерческую поддержку" форка опенсорного продукта. А так да - "куй железо не отходя от кассы!"
Проблема проявляется лишь на дистанции. Через 3-5 лет собственное железо окупается, а облачная аренда – история бесконечная. То есть уже через 4-5 лет совокупные затраты плюс-минус выравнятся, а дальше собственный дата-центр начнет работать в плюс.
Если говорить про чистый IaaS и листовые цены, то собственное железо окупается в среднем за 10-12 месяцев в аналогичных ресурсах CPU/RAM/SSD и аренде стойки в Tier-3 ЦОД. Т.е работать в плюс начинает практически со 2-го года. Но и облачники, если им интересно затащить к себе конкретного клиента, бывает дают соответствующую скидку.
В кластере, собранном из двух СХД (scale-out), полный отказ одного контроллерного шасси логичным образом приводит к недоступности всех его дисков для "живой" полки. Только это происходит не в момент отказа системного диска, а когда контроллеры полки полностью недоступны. Такой сценарий - достаточно маловероятен даже при таком серьёзном сбое как авария системного диска.
Понятно. Спасибо. Т.е. получается эти кластерные конфигурации на двухконтроллерных головах это не про доступность при умирании одной головы, а про производительность. А у нетаппов также ?
HP ушел из России, т.п вам будут оказывать менеджеры, которые вам продали msa из серого импорта.
Покупайте у нормальных системных интеграторов (а не у перекупных "рогов и копыт") и т.п. вам будут обеспечивать его сертифицированные сервисные инженеры (в том числе из ушедших вендоров) и даже on-site.
Такой подход нас очень выручил в еще одном интересном кейсе: в один момент на такой же четырехконтроллерной системе Dorado 5000 V6 одновременно сломались системные диски в обоих контроллерах.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
А с какими проблемами, связанными с отказом компонентов в СХД, сталкивались вы?
Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)
Но когда кейсов уже стало несколько десятков, пришлось искать другое решение.
Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)
А по факту оно примерно так не только лишь всегда через пару/тройкулет от go live:) Это в ECC 6.0 все было в абапе, а в S/4HANA теперь БД-монстры, выжирающие селектом по 500+GB оперативы. И в "стандарте" в том числе.
Требования к RAM для сервера БД зависят от ожидаемого количества данных во всех развертываемых модулях, поскольку вся БД in-memory
Начиная с S/4HANA 2020 можно использовать NSE (будет как классическая CУБД работать через буффер-кэш), если с памятью совсем напряг, но, естественно с некоторымоверхедом
На практике для стандартного набора модулей (бухучет, управленческий учет, казначейство, закупки и склад, сбыт, производство, техобслуживание и ремонты) от 256 до 512 гигов, для особо тяжелых случаев 1 TB.
Для S/4HANA на 1000 конкурентных юзеров 1TB RAM БД это скорее для особо легких случаев без тяжелого Z-кода (CDS, AMDP), что практически фантастика :)
Ну вот за прошлый год выручка Спортмастера составил 170 ярдов. Т.е. условно-примерно 465 лямов в день. Неплохо за день простоя. Безусловно каждый крупный бизнес сам выбирает надо ли оно ему это DR или "и так сойдет". А если бы не затопило и высушили за день, а сгорело ?
Сбер мигрирует на коммерческий Pangolin. ВТБ своими core-системами мигрирует на ванильку ? Или может все-таки на реестровый форк за деньги ?
Ох уж эти сказочники-импортозаместители....Произошла она (но это не точно) в основном в госухе (которая денег не считает) и по понятными причинам. Коммерсы за редким исключением продолжают сидеть на "Oracle, Microsoft SQL Server и DB2" ибо привозить себе собственными руками и за свой счет
геморой на головупроблемы с давно и нормально работающими системамидураковжелающих не особо много. А самое главное "чтобы что?"Как говорится "на безрыбье и рак рыба"
Еще бы ценник адекватный они предложили за свои "дополнительные функции и коммерческую поддержку" форка опенсорного продукта. А так да - "куй железо не отходя от кассы!"
Cпасибо, что поделились. Редко кто отвечает на вопросы про ТТХ инфры.
А сколько было ядер на оракле (single instance или RAC/Exadata ?) и сколько стало на шардмане с учетом всех шардов и их реплик ?
Спасибо за кейс.
Какие ресурсы (кол-во ядер, объем памяти) были на БД-хостах с ораклом и теперь на панголине ?
Приложения переписывать под панголин не пришлось ?
Т.е. наличие Arenadata DB в списке форков PostgreSQL нисколько не смущает?
Вы точно "менеджер по развитию решений СУБД"?
Если говорить про чистый IaaS и листовые цены, то собственное железо окупается в среднем за 10-12 месяцев в аналогичных ресурсах CPU/RAM/SSD и аренде стойки в Tier-3 ЦОД. Т.е работать в плюс начинает практически со 2-го года. Но и облачники, если им интересно затащить к себе конкретного клиента, бывает дают соответствующую скидку.
Понятно. Спасибо. Т.е. получается эти кластерные конфигурации на двухконтроллерных головах это не про доступность при умирании одной головы, а про производительность. А у нетаппов также ?
Покупайте у нормальных системных интеграторов (а не у перекупных "рогов и копыт") и т.п. вам будут обеспечивать его сертифицированные сервисные инженеры (в том числе из ушедших вендоров) и даже on-site.
А вот в таком кластерном сетапе и при такой аварии вторая контроллерная голова каким образом получает доступ к дискам в первой голове и подключенным к ней полкам ?
Как то помер мидплейн в одном из IBM V7000G2 ("никогда такого не было и вот опять" (c) инженер IBM)
Как хорошо, что не позарились в свое время на дорады и остались на сторвайзах. Шестое чувство недаром подсказывало, что "не надо оно вам" ;)
Спасибо.
Интересно. Спасибо. А можете поделиться временем выполнения q78.sql из TPC-DS для варианта scale=1000 ?
А с каких резервных копий восcтанавливали, если "злоумышленник использовал доступ бывшего сотрудника, чтобы удалить резервные копии с лент" ?
Скринов из HMC вроде не было. Может хоть до паверов не добрались....
А больше HDD на одну ноду поддерживается ? Что под капотом и как обеспечивается отказоустойчивость ?
А по факту оно примерно так не только лишь всегда через пару/тройку лет от go live :) Это в ECC 6.0 все было в абапе, а в S/4HANA теперь БД-монстры, выжирающие селектом по 500+GB оперативы. И в "стандарте" в том числе.
Начиная с S/4HANA 2020 можно использовать NSE (будет как классическая CУБД работать через буффер-кэш), если с памятью совсем напряг, но, естественно с некоторым оверхедом
Для S/4HANA на 1000 конкурентных юзеров 1TB RAM БД это скорее для особо легких случаев без тяжелого Z-кода (CDS, AMDP), что практически фантастика :)
Из синхронных реплик с DR-сайта вестимо, ну если по правильному
Ну вот за прошлый год выручка Спортмастера составил 170 ярдов. Т.е. условно-примерно 465 лямов в день. Неплохо за день простоя. Безусловно каждый крупный бизнес сам выбирает надо ли оно ему это DR или "и так сойдет". А если бы не затопило и высушили за день, а сгорело ?