Миф: как IBM победил БЭСМ

[StrangerR]

Да, я думаю память такая дорогая потому что там особенные, неметрические байты

Там обычные байты, но это МФ и эта memory - redundant array of independent memory (RAIM).

А у Вас это во-первых не МФ мемори, а во-вторых... как там у Вас с RAIM?

Можно включать RAIM, но мы никогда не делали, так как проще зеркалить то что критическое.

[StrangerR]

О, спасибо за конкретику
$1500/1Gb RAM
Только память одного нашего ESX стоила бы 288K
А всех десяти 2.88M
Это только PROD, и только в одном Datacenter, и только память

Ужас!

Даа. У нас 4 терабайта пампяти в двух облаках. Это что, 6 миллионов нам заплатить надо было бы??

[StrangerR]

Или я Вас не понимаю или Вы меня.

Я правильно понимаю что Вы говорите о двух систем instances с двумya базами которые между собой занимаются репликацией данных в реальном времени (online)? Один instance работает с юзерами второй только отслеживает изменение данных. Если первый сдох юзера перекидываются на второй.

У нас используется реальный дисковый mirror (похоже с легкой руки MS термин "mirror" стал использоваться и для "репликация"). Всех дисков на которых размещается Production. В случае дизастера, на DR сайте делается загрузка системы и стартуют БД и app. serevra. Чем этот подход лучше по нашему по МФ-скому? DR сайт - это второй МФ на котором выполняются другие Production, других приложений. Если на нем держать "горячий" standby, то для него нужны дополнительные MIPS. Посколько DR не так уж и часто происходит, а за доп MIPS платить придется всегда, то это по крайней мере некрасиво, а на самом деле было бы идиотизмом (я понимаю у Вас все дешевое, $10000 тута 10 сюда, это ж ведь не миллионы).

Фактически в ожидании DR для DR мы не тратим цента за МФ, мы платим только за диски и за их возможность самореплицироваться.

ТО что вы пишете, тоже иногда делается. Но это совсем не эквивалентно зеркалу базы данных, это намного слабее. Ну например, как вы патчи на сервер базы данных будете накладывать?

У нас
- накладываем на стендбай
- переключаем базу
- накладываем на праймари

Или вот мы делали апгрейд MS SQL 2005 -> 2008. Даунтайм был 2 минуты суммарно. Потому что операция выглядела так
- делаем апгрейд на стендбае. Праймари работает на 2005, стендбай на 2008. 2008 может миррорить 2005. Сам апгрейд занимает где то пару часов, так как там -патч, апгрейд, сервиспак, патч- надо наложить.
- сделали, все проверили. Переключили. Даунтайм 1 минута.
- так как 2005 не может миррорить 2008 то зеркало встало на паузу. Апгрейдим бывший праймари.
- заапгрейдили, запустили, зеркало синхронизовалось.
- переключили назад на основной праймари. Даунтайм еще 1 минута.

Как бы тут нам помогло реплицирование дисков? Зеркало в первую очередь нужно не для защиты от сбоя железа хотя и это не вредно (а если база напишеть чушь в файл?) а для бесперебойности сервиса. Аналогично с кластером NFS - он еще ни разу не был нужен для защиты от сбоя но постоянно используется для разных апдейтов и прочего... без прерывания сервиса.

"Planned DR" то можно совершенно бесплатно просто раз в пару минут скидывать архивные логи на стебай, который будет их накатывать

Так это и есть DG в режиме ARCH. Он так и работает. А я так примерно реализую DR в случае MS SQL (реплицирую бэкапы и имею скрипт для их автоматического накатывания)

[Dmitry67]

О, спасибо за конкретику
$1500/1Gb RAM
Только память одного нашего ESX стоила бы 288K
А всех десяти 2.88M
Это только PROD, и только в одном Datacenter, и только память

Ужас!

Даа. У нас 4 терабайта пампяти в двух облаках. Это что, 6 миллионов нам заплатить надо было бы??

А у нас 2терабайта на datacenter в Prod. Таких 4. Плюс dev, qa, vdi. Итого около 12т

[Dmitry67]

А у нас с downtime хорошо... в общем, весь викенд )

[StrangerR]

А у нас с downtime хорошо... в общем, весь викенд )

Неа, мы тут супер мажорный апгрейд системы (переход на другие базовые библиотеки) загоняем в 12 часов, чтобы уложиться в 1 сутки. Больше - ни за что! В крайнем случае придется RO режим делать или SSD ставить для ускорения.

(Девелоперы блин. Загоняют загоняют.

Первый запуск. 100 часов и 400 гиг лог. Надавали по шапкам.
Второй запуск, выкинули ненужное - 40 часов.

(Я уж скриптик написал переписав роскошные drop from TABLE where УСЛОВИЕ - нельзя ТАКИЕ конструкции писать для массовых удалений!)

...
Десятый запуск. Основной liquibase 26 часов, миграция документов 2 часа.
...
Очередной. Основной 12 часов (ура!) зато миграция документов 24 часа (сломали!)

И так далее. Хвост вытащят нос увязне. Нос вытащят лапа увязнет... Основную. починят, доки починят, месячная обработка 4 дня идет... и все по кругу...
Уже 3 месяца отладка и еще пару месяцев впереди. Но даунтайм будет 10 - 12 часов максимум. Больше - никто не даст. Какие _весь викенд_?

[Palych]

Даа. У нас <до фига>

А у нас <до фигища>

Не флейма ради, ещё раз спрошу - вы как-то замеряете необходимое количество памяти, или просто берёте самое большое что есть?

[Dmitry67]

У нас биржа, они отдыхают на выходных )

[Easbayguy]

В общем программисты/базы все хреновей и хреновей, необходимость держать все в памяти указывает на очень плохой дизайн приложения, фиговый движок и маленький обьем данных.

[StrangerR]

Даа. У нас <до фига>

А у нас <до фигища>

Не флейма ради, ещё раз спрошу - вы как-то замеряете необходимое количество памяти, или просто берёте самое большое что есть?

Есть инвентори, есть репорт сколько имеется сколько разместили сколько ОС (ВМваря) не дала. Обычная цифра например
- сервер 144 гига
- размещено 190 гигов
- ВМ хост не додал где то 12 гигов,

Причем есть статистика примерно сколько можно наплодить vCPU до того как система начнет уже недодавать CPU вм-кам.

Все естественно по разному в девелопменте (цифры выше из девелопмента) и в продакшенах (там всегда 100% и часто резервирование стоит). Примерно HP G7 сервер набивается 144 - 192 гигов до того как по процессору его скушают. Кое какие приложения кушают быстрее но при наличии нескольких десятков хостов их удается раскидать ровным слоем.

[Palych]

В общем программисты/базы все хреновей и хреновей, необходимость держать все в памяти указывает на очень плохой дизайн приложения, фиговый движок и маленький обьем данных.

Если вдуматься - что наша память? Кеш.
Если нужно что-то читать/писать с/на диск[а] больше одного раза - RAM всегда быстрее диска будет.
Если все данные влезают в память кто виноват что их оказалось недостаточно?
Если фиговость позволяет сделать проще и надёжнее - почему бы не воспользоваться?

[zVlad]

Или я Вас не понимаю или Вы меня.
.....

ТО что вы пишете, тоже иногда делается. Но это совсем не эквивалентно зеркалу базы данных, это намного слабее. Ну например, как вы патчи на сервер базы данных будете накладывать?
....

Нет, Вы меня все таки не поняли. Зеркалируется все, и БД и система и вообще все, все. Все диски на которых работает instance.

Патчи накладываются на Production и тут же зеркалируются на зеркало, которое пассивно, только диски. Это новое для Вас похоже, Вы о таком не слышали, походу.

[zVlad]

... Сам апгрейд занимает где то пару часов, так как там -патч, апгрейд, сервиспак, патч- надо наложить.
- сделали, все проверили. Переключили. Даунтайм 1 минута.
- так как 2005 не может миррорить 2008 то зеркало встало на паузу. Апгрейдим бывший праймари.
- заапгрейдили, запустили, зеркало синхронизовалось.
- переключили назад на основной праймари. Даунтайм еще 1 минута.

Как бы тут нам помогло реплицирование дисков? Зеркало в первую очередь нужно не для защиты от сбоя железа хотя и это не вредно (а если база напишеть чушь в файл?) а для бесперебойности сервиса. Аналогично с кластером NFS - он еще ни разу не был нужен для защиты от сбоя но постоянно используется для разных апдейтов и прочего... без прерывания сервиса.
...

Те два часа пока Вы упгрэдили примари у вас не было ДР защиты. Если бы в течении тех двух часов вы бы потеряли standby то вы бы потеряли до двух часов работы юзеров. Согласны.

Вы явно не в полной мере понимаете что такое DR. Это видно из последнего Вашего абзаца. Это абзац!

[StrangerR]

DR защита у меня была. Зеркало не обеспечивает DR защиту а обеспечивает бесперебойность главного сервиса. Да если бы сервер упал то пришлось бы поднимать с бэкапа стендбай или крутить его назад и накатывать логи. Или переключиться на DR базу (так как мейнтененс делался в выходные то даже при этом потерял нескольких минут ничего бы страшного не составила). Но и только.

Это вы не понимаете что такое продакшен конфигурация. Рисую

Code: Select all

SITE1                                                  SITE2
 DB01                        ---> ASYNC replciation --+
   ^                                                   !
   !                                                   !
 SYNC replication                                      +---> DRDB01
   !                                                   !
  DB02                       ---> ASYNC replication  --+

Нет, Вы меня все таки не поняли. Зеркалируется все, и БД и система и вообще все, все. Все диски на которых работает instance.

Это хороший подход но не без кучи граблей. Во первых, такое зеркало никогда не будет синхронным. во вторых, оно зазеркалирует все изменения в том числе например и 100 гигов временной таблицы. В третьих, оно же зазеркалирует ошибочно записанные данные из за которых база грохнулась. В четвертых, если 2 сайта, то там кое что разное бывает. Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.

[zVlad]

DR защита у меня была. Зеркало не обеспечивает DR защиту а обеспечивает бесперебойность главного сервиса. ..... Такое зеркалирование поддерживается той же VMware но вот только это именно DR а не бесперебойность сервиса.

Вы не только в DR ничего не понимаете, но и с зеркалированием запутались напрочь.