Size: a a a

2020 February 28

AS

Alexey Shumkin in Delphi & Lazarus
Andrey Zubov
я вполне допускаю что унигуй как-то по хитрому протаскивает идентификаторы сессий
да походу sticky sessions ))...
источник

AZ

Andrey Zubov in Delphi & Lazarus
хз, но у нас по словам админа был настроен тупой проброс порта во внутреннюю подсеть на единственный сервер и единственный порт и оно уже начинало работать с нюансами
источник

AS

Alexey Shumkin in Delphi & Lazarus
Andrey Zubov
хз, но у нас по словам админа был настроен тупой проброс порта во внутреннюю подсеть на единственный сервер и единственный порт и оно уже начинало работать с нюансами
ну, дык, репортили юнигую ? )
источник

AZ

Andrey Zubov in Delphi & Lazarus
да хз, мы пытались порешать с фаршадом, но там блин надо было плотно сидеть с мониторингом, мы просто обошли эту проблему и забили
источник

DB

Dmitry Belkevich in Delphi & Lazarus
it в медицинке:

[В ответ на Denis]
Там архитектурная проблема. Я бился в свое время в кровь, но бесполезно. На цодах РТК в VM включен автоматический менеджмент high availability. Это когда мониторится загрузка железа и в случае критичных проблем или падения железа на какой то из нод - виртуалка автоматически переезжает на менее загруженную ноду. В связи с этим, там виртуалка не может быть больше чем 16 гигов по-моему, или 32 гб. В виду того, что утром всё перегружено, начинается нахуйненужное движение виртуалок по железу. В итоге, картина выглядит следующим образом: сработал сенсор по процессорам, потащил виртуалку в свободный ресурс, от этого сработали сенсор по дискам, потащил другие виртуалки в другие ноды виАппа, в итоге встает колом и интерсеть и весь кластер тупит. Чего в итоге делают админы? Перезапукают кластер. Каждый день. Каждое утро. Вместо того чтобы отключить эту возможность виртуалки перемещаться
источник

DB

Dmitry Belkevich in Delphi & Lazarus
вот примерно реалии жизни (мисы и их тормоза)
источник

AS

Alexey Shumkin in Delphi & Lazarus
Dmitry Belkevich
it в медицинке:

[В ответ на Denis]
Там архитектурная проблема. Я бился в свое время в кровь, но бесполезно. На цодах РТК в VM включен автоматический менеджмент high availability. Это когда мониторится загрузка железа и в случае критичных проблем или падения железа на какой то из нод - виртуалка автоматически переезжает на менее загруженную ноду. В связи с этим, там виртуалка не может быть больше чем 16 гигов по-моему, или 32 гб. В виду того, что утром всё перегружено, начинается нахуйненужное движение виртуалок по железу. В итоге, картина выглядит следующим образом: сработал сенсор по процессорам, потащил виртуалку в свободный ресурс, от этого сработали сенсор по дискам, потащил другие виртуалки в другие ноды виАппа, в итоге встает колом и интерсеть и весь кластер тупит. Чего в итоге делают админы? Перезапукают кластер. Каждый день. Каждое утро. Вместо того чтобы отключить эту возможность виртуалки перемещаться
🤦‍♂️
источник

ГМ

Геннадий Малинин in Delphi & Lazarus
Dmitry Belkevich
it в медицинке:

[В ответ на Denis]
Там архитектурная проблема. Я бился в свое время в кровь, но бесполезно. На цодах РТК в VM включен автоматический менеджмент high availability. Это когда мониторится загрузка железа и в случае критичных проблем или падения железа на какой то из нод - виртуалка автоматически переезжает на менее загруженную ноду. В связи с этим, там виртуалка не может быть больше чем 16 гигов по-моему, или 32 гб. В виду того, что утром всё перегружено, начинается нахуйненужное движение виртуалок по железу. В итоге, картина выглядит следующим образом: сработал сенсор по процессорам, потащил виртуалку в свободный ресурс, от этого сработали сенсор по дискам, потащил другие виртуалки в другие ноды виАппа, в итоге встает колом и интерсеть и весь кластер тупит. Чего в итоге делают админы? Перезапукают кластер. Каждый день. Каждое утро. Вместо того чтобы отключить эту возможность виртуалки перемещаться
Мдаа.. вот бы у админов тоже мозги переезжали, когда тупят на менее загруженную ноду, а на старую вставали по развитее
источник

AS

Alexey Shumkin in Delphi & Lazarus
Dmitry Belkevich
it в медицинке:

[В ответ на Denis]
Там архитектурная проблема. Я бился в свое время в кровь, но бесполезно. На цодах РТК в VM включен автоматический менеджмент high availability. Это когда мониторится загрузка железа и в случае критичных проблем или падения железа на какой то из нод - виртуалка автоматически переезжает на менее загруженную ноду. В связи с этим, там виртуалка не может быть больше чем 16 гигов по-моему, или 32 гб. В виду того, что утром всё перегружено, начинается нахуйненужное движение виртуалок по железу. В итоге, картина выглядит следующим образом: сработал сенсор по процессорам, потащил виртуалку в свободный ресурс, от этого сработали сенсор по дискам, потащил другие виртуалки в другие ноды виАппа, в итоге встает колом и интерсеть и весь кластер тупит. Чего в итоге делают админы? Перезапукают кластер. Каждый день. Каждое утро. Вместо того чтобы отключить эту возможность виртуалки перемещаться
там ещё архитектурная проблема с том, что нагрузка распределяется каким-то странным образом - перемещением виртуалки ))
что говорит о монолитной какой-то системе... которая крутится в ней, очевидно
источник

DB

Dmitry Belkevich in Delphi & Lazarus
ну я честно такое вообще первый раз слышу ) какая-то совсем уж хитрая фича. и сверх-виртуализация
источник

AS

Alexey Shumkin in Delphi & Lazarus
Dmitry Belkevich
ну я честно такое вообще первый раз слышу ) какая-то совсем уж хитрая фича. и сверх-виртуализация
да нет, обычное дело )
VMWare умеет, вроде
источник

AS

Alexey Shumkin in Delphi & Lazarus
Dmitry Belkevich
ну я честно такое вообще первый раз слышу ) какая-то совсем уж хитрая фича. и сверх-виртуализация
почти кстати, про LVM слышал? )
источник

DB

Dmitry Belkevich in Delphi & Lazarus
Alexey Shumkin
да нет, обычное дело )
VMWare умеет, вроде
да, может. я как-то больше не админ всё таки )
источник

AS

Alexey Shumkin in Delphi & Lazarus
Alexey Shumkin
почти кстати, про LVM слышал? )
почти то же самое, только про диски )
источник

DB

Dmitry Belkevich in Delphi & Lazarus
LVM да, знаю, сталкивались уже
источник

DB

Dmitry Belkevich in Delphi & Lazarus
сталкивались хитро причем ) были партиции под LVM распределены. мы спросили - где делать место под том - сказали - вот на этот жесткий и ставьте. сказали - пофиг - форматируйте. отформатировали. после этого не стало больше операционки на сервере ) поднимали дня два
источник

AS

Alexey Shumkin in Delphi & Lazarus
Dmitry Belkevich
сталкивались хитро причем ) были партиции под LVM распределены. мы спросили - где делать место под том - сказали - вот на этот жесткий и ставьте. сказали - пофиг - форматируйте. отформатировали. после этого не стало больше операционки на сервере ) поднимали дня два
и LVM виновата? )))
источник

DB

Dmitry Belkevich in Delphi & Lazarus
да не виновата. просто говорю )
источник

AS

Alexey Shumkin in Delphi & Lazarus
я тогда расскажу successful story ))
на сервере сборок, который я на прошлой работе поддерживал, я , к счастью, сразу LVM использовал...
один винт на 1ТБ
потом когда закончивалось место, купили ещё два по 1ТБ , чтобы RAID-1 хотя бы сделать..
воткнули их.. даунтайм был 5 минут )
затем уже пока сервер работал, я разбил их, сделал программный RAID,
за счёт LVM подключил в существующую группу, сказал "мигрурируй данные " со старого диска, затем выключил старый диск из группы... всё...
теперь 1ТБ в рейде-1 и 1ТБ в резерве и для некритичных данных...
всё это - онлайн... даунтайм был, повторюсь, только чтобы воткнуть винты
источник

AS

Alexey Shumkin in Delphi & Lazarus
я как вспомню, как мудохался с MSDOS-партициями когда-то...🙈
источник