SAPфорум.RU https://sapboard.ru/forum/ |
|
SAP on VmWare. Как преодолеть порог в 2ТБ. https://sapboard.ru/forum/viewtopic.php?f=14&t=95541 |
Страница 1 из 2 |
Автор: | RikoNw [ Вт, окт 03 2017, 14:06 ] |
Заголовок сообщения: | SAP on VmWare. Как преодолеть порог в 2ТБ. |
Доброго дня! Вопрос к тем, кто виртуализировал SAP. Размер VMDK диска под /oracle и /usr приближается к 2ТБ и тут вижу три варианта: - Расширить VMDK более 2 ТБ и потерять возможность storage vmotion - Расширить VMDK более 2 ТБ с разбивкой VMDK по 2 ТБ и не потерять возможности storage vmotion - Создать следующий VMDK и перенести туда, например, датафайлы базы Есть ли какие-то еще варианты и какой более правильный по вашему мнению ? Спасибо. з.ы. отказаться от виртуализации не предлагать, виртуализация рулит |
Автор: | avlag [ Вт, окт 03 2017, 16:32 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
RikoNw написал: Доброго дня! Вопрос к тем, кто виртуализировал SAP. Размер VMDK диска под /oracle и /usr приближается к 2ТБ и тут вижу три варианта: - Расширить VMDK более 2 ТБ и потерять возможность storage vmotion - Расширить VMDK более 2 ТБ с разбивкой VMDK по 2 ТБ и не потерять возможности storage vmotion - Создать следующий VMDK и перенести туда, например, датафайлы базы Есть ли какие-то еще варианты и какой более правильный по вашему мнению ? Спасибо. з.ы. отказаться от виртуализации не предлагать, виртуализация рулит Добавить диск, положить на него датафайлы. При этом не забыть диск зацепить за свой дисковый контроллер. Оська какая стоит? А то для линухов под vmware в параметрах ядра надо несколько нужных вещей дописывать. |
Автор: | RikoNw [ Ср, окт 04 2017, 13:00 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
Да собственно говоря на системах и на Windows и на Linux потихоньку приближается порог.. А что это за параметры ядра такие ? Чего-то не слышал.. |
Автор: | avlag [ Ср, окт 04 2017, 13:15 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
RikoNw написал: Да собственно говоря на системах и на Windows и на Linux потихоньку приближается порог.. Ну так, еще один диск - и все решается. Диск 2 Tb одним куском не сильно комильфо, кмк. Я надеюсь логи базы на отдельном диске? Вообще у vmware есть интересные документы. Например про Oracle можно почитать. Цитата: А что это за параметры ядра такие ? Чего-то не слышал.. Для grub2 в /etc/default/grub GRUB_CMDLINE_LINUX="nosoftlockup intel_idle.max_cstate=0 mce=ignore_ce elevator=noop ipv6.disable=1 net.ifnames=0 vmw_pvscsi.cmd_per_lun=254 vmw_pvscsi.ring_pages=32 rhgb quiet" ipv6.disable=1 и net.ifnames=0 - по необходимости, первое отключает ipv6, второе приводит имена сетевых интерфейсов к старым стандартам (eth0) elevator=noop - грубо - отключение линухового оптимизатора очередей дисковых операций. У vmware свое есть Ну а про остальное можно погуглить что и зачем Кста, у винды обязательно схему питания поставить в режим производительности. Чтобы ядра спать не ходили. |
Автор: | sap2me [ Пн, окт 09 2017, 08:19 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
RikoNw написал: Есть ли какие-то еще варианты и какой более правильный по вашему мнению ? лично я бы разбил систему на 2 части: ВМ под сервер с БД и ВМ под САП. Первое бэкапить/резервировать средствами СУБД онлайн, второе - загасил машинку с сапом, положил образ в сторонку и продолжаем. Если доверяете онлайновым вмваревым бэкапам то можно и ими. |
Автор: | RikoNw [ Пн, окт 09 2017, 09:21 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
sap2me написал(а): RikoNw написал: Есть ли какие-то еще варианты и какой более правильный по вашему мнению ? лично я бы разбил систему на 2 части: ВМ под сервер с БД и ВМ под САП. Первое бэкапить/резервировать средствами СУБД онлайн, второе - загасил машинку с сапом, положил образ в сторонку и продолжаем. Если доверяете онлайновым вмваревым бэкапам то можно и ими. Да, тоже вариант, только боюсь будет некоторая просадка производительности, ведь сервер СУБД и инстанция начнут общаться по сети, пусть и виртуальной.. |
Автор: | avlag [ Пн, окт 09 2017, 09:40 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
RikoNw написал: sap2me написал(а): лично я бы разбил систему на 2 части: ВМ под сервер с БД и ВМ под САП. Первое бэкапить/резервировать средствами СУБД онлайн, второе - загасил машинку с сапом, положил образ в сторонку и продолжаем. Если доверяете онлайновым вмваревым бэкапам то можно и ими. Да, тоже вариант, только боюсь будет некоторая просадка производительности, ведь сервер СУБД и инстанция начнут общаться по сети, пусть и виртуальной.. У вас база, видимо, лежит на SSD? В любом другом случае надо очень постараться построить хранилище, которое умеет отдавать данные заметно быстрее гигабитной сетки. Это я к тому, что скорость до сих пор определяется скоростью работы СХД. Если вы живете на одном хосте vmware и у вас хватает ресурсов (процессор/память) на обе виртуалки, то никакого кайфа от разделения не будет. Смысл в разделении есть исключительно, если на хосте уже нет свободных ресурсов а система хочет больше памяти. Тогда есть смысл в разделении. Но и то, гораздо проще на соседнем хосте поставить еще одну аппликуху, чем делить живую систему. Просадкой производительности по сетке можно пренебречь Особенно если у вас хосты связаны по десятке. Да даже и гигабита хватает на достаточно большие базы. Скорость сетки будет определять исключительно время загрузки системы. Точнее даже не это, а скорость забития буферов на аппликухе данными из БД. А буфера забиваются очень даже постепенно. |
Автор: | RikoNw [ Пн, окт 09 2017, 09:59 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
30% SSD, комбинированная СХД, да, согласен, хоть сетью можно пренебречь, все же делить аппликуху и СУБД бессмысленно в моем случае. Остановился на диске E:\ для части датафайлов |
Автор: | RikoNw [ Пн, окт 09 2017, 10:07 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
avlag, а про логи базы на отдельном диске, вы имеете в виду оперативные логи или архивлоги? Я складываю архивлоги каждый час сразу на сетевой диск, чтобы если при самом плохом раскладе, даже если с сервером что-то случилось физически можно было докатить базу до последнего часа. Просто можно еще зеркало оперативных логов держать на другом хосте, но есть ли в этом смысл.. |
Автор: | avlag [ Пн, окт 09 2017, 10:43 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
RikoNw написал: avlag, а про логи базы на отдельном диске, вы имеете в виду оперативные логи или архивлоги? Я складываю архивлоги каждый час сразу на сетевой диск, чтобы если при самом плохом раскладе, даже если с сервером что-то случилось физически можно было докатить базу до последнего часа. Просто можно еще зеркало оперативных логов держать на другом хосте, но есть ли в этом смысл.. Складывание архивных логов на более медленный носитель, чем тот, на котором живут оперативные, может привести к ситуации (хотя и редкой), когда свежий оперативный лог заполняется быстрее, чем данные из предыдущего сливаются в архивный. После чего мы начинаем работать на запись в базу со скоростью диска, отданного под архивные логи Так что с выносом архивов на сетку надо быть аккуратным. С дублем оперативных логов на соседнем хосте - таже ситуация А вообще, мне не совсем понятно беспокойство насчет архивных логов и падения хоста. У вас же все данные живут на внешнем хранилище, как я понял, которое живет вне зависимости от жизнеспособности хоста. А какой тогда смысл куда-то еще лить архивные логи? Ну упал сервер, где жила система. Ну и земля ему пухом. На соседнем хосте, подключенном к той же СХД, поднимаем систему в том же состоянии. Ну, точнее, база будет подниматься из состояния аварийной перезагрузки. Но расположение архивных логов в другом месте никак не поможет жизнеспособности системы, кмк. Я бы понял такую схему, когда у вас отсутствует общая СХД. Т.е. один хост - одна дисковая полка. Но это не очень разумно А по раскидке дисков, в идеале, и оперативные надо на отдельный диск со своим контроллером вешать, и с архивными аналогично поступать. Благо в виртуальной среде можно диски под нужный размер нарезать. Т.е. в случае с виндой я бы так все нарезал: 1-й диск под ОСЬ - 64 Gb минимум, с учетом постоянных обновлений, которые кушать хотят, и желательных 20% свободного места для минимизации фрагментации NTFS 2-й диск под бинарники БД и системы. 3-й диск под данные БД. По мере заполнения добавляем еще диск(и). 4-й диск под Redo (Интереснее всего положить на быстрый массив). Если есть необходимость в зеркале Redo - можно и ему отдельный диск. 5-й диск под Archive В общем-то все сводится к паре абзацев из рекомендаций vmware Цитата: VMware highly recommends using multiple paravirtual SCSI (PVSCSI) controllers for the database virtual
machines or virtual machines with high I/O load. The use of multiple paravirtual SCSI controllers allows the execution of several parallel I/O operations inside the guest operating system. PVSCSI drivers are installed when VMware Tools is installed on the virtual machine. VMware also highly recommends separating the Redo/Log I/O traffic from the data file I/O traffic through separate virtual SCSI controllers. |
Автор: | RikoNw [ Пн, окт 09 2017, 11:05 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
У меня просто режим паранойи, архивлоги держу на случай попадания метеорита прямо в СХД Ну или на случай повреждения VMDK. Психологически не могу пока принять мысль о локальном хранении, но попробую Да, если это будут отдельные vmdk будет лучше, например, диск с архивлогами можно реплицировать средствами Veeam. А так да, ночью, когда база переходит в backup mode, иногда, случается ситуация ожидания записи архивлога по сети, ведь база все изменения начинает хранить в оперативных журналах и архивлогах, дабы датафайлы оставались консистентными на момент их бэкапа. |
Автор: | avlag [ Пн, окт 09 2017, 11:41 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
RikoNw написал: У меня просто режим паранойи, архивлоги держу на случай попадания метеорита прямо в СХД Ну или на случай повреждения VMDK. Психологически не могу пока принять мысль о локальном хранении, но попробую Чтобы режим паранойи стал менее назойливым надо вторую СХД в соседнем ЦОД'е, на расстоянии не менее 100 км от первого, и реплицироваться средствами СХД. Ну и кластерок там же вмварьный, с готовой инфраструктурой по поднятию системы, навернувшейся в первом ЦОД'е... А если по жизни, то первым шагом с бизнеса надо стребовать допустимое время простоя при попадании метеорита, т.е. время на дизастер рекавери, и допустимый объем потерянных данных, которые могут возникнуть при переезде в другой ЦОД. После этого посчитать, сколько это будет стоить и, постепенно, уменьшая стоимость и увеличивая время, прийти к консенсусу Цитата: Да, если это будут отдельные vmdk будет лучше, например, диск с архивлогами можно реплицировать средствами Veeam. А так да, ночью, когда база переходит в backup mode, иногда, случается ситуация ожидания записи архивлога по сети, ведь база все изменения начинает хранить в оперативных журналах и архивлогах, дабы датафайлы оставались консистентными на момент их бэкапа. А вообще сейчас интересно все начинает складываться. После построения полноценной отказоустойчивой системы внезапно приходит понимание, что архайвлоги нужны исключительно при восстановлении системы из бэкапа на определенный момент времени. А после этого возникает крамольная мысль (если система живет в распределенном кластере), а на кой ляд нужны бэкапы? На случай, если дизастер пришел сразу в два ЦОДа? Придется наращивать группировку! А бэкапы, тогда, делать еще и в четвертое место, да еще и ежедневную выносную копию бэкапов (кстати вимом хорошо организовывается )! Но тут перед глазами встает картинка с героической фигуркой админа, ползущего по развалинам с дисками выносного бэкапа в сторону квартиры вышестоящего руководства с вопросом на устах: - Куда ставить-то?! |
Автор: | sap2me [ Вт, окт 10 2017, 03:11 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
avlag написал: Если вы живете на одном хосте vmware и у вас хватает ресурсов (процессор/память) на обе виртуалки, то никакого кайфа от разделения не будет. Смысл в разделении есть исключительно, если на хосте уже нет свободных ресурсов а система хочет больше памяти. Тогда есть смысл в разделении. Но и то, гораздо проще на соседнем хосте поставить еще одну аппликуху, чем делить живую систему. чет мне кажется в мире не так много товарищей которым проще рядом поставить второй апликэйшен сервер чем перенести виртуалку на другой хост в пуле серверов vmware. А кайф в том что оракл резервируется и бэкапится средствами оракла, а виртуалка с саповым каким-нибудь PI относительно статична и достаточно закопировать ВМ в сторонку пару раз в год. А потом развернуть ее быстро и почти где угодно потому что внутри нет многотерабайтной БД. И голова не болит что чего то из /etc или /usr/local/bin забыл скопировать. |
Автор: | sap2me [ Вт, окт 10 2017, 03:20 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
RikoNw написал: У меня просто режим паранойи, архивлоги держу на случай попадания метеорита прямо в СХД Ну или на случай повреждения VMDK. Психологически не могу пока принять мысль о локальном хранении, но попробую главное средство от паранойи это стэндбай. если у вас его до сих пор нет ,то я надеюсь вы сказали начальству сколько у вас будет простой в случае если сдохнет железяка и вы начнете разворачивать вашу многотерабйтную БД. При том что у вас вообще есть где разворачивать копировать диск с архивлогами мне кажется излишним. Для тру параноиков есть стэндбай с передачей и накатом логов в соседнее здание. И настраивается еще одна БД(любая) которая так же принимает логи и складирует их куда-то, но находится она в третьем здании(соседнем городе, если каналы позволяют) и не обязана быть такой же большой как продуктив. |
Автор: | avlag [ Вт, окт 10 2017, 07:33 ] |
Заголовок сообщения: | Re: SAP on VmWare. Как преодолеть порог в 2ТБ. |
sap2me написал(а): Для тру параноиков есть стэндбай с передачей и накатом логов в соседнее здание. И настраивается еще одна БД(любая) которая так же принимает логи и складирует их куда-то, но находится она в третьем здании(соседнем городе, если каналы позволяют) и не обязана быть такой же большой как продуктив. Соседнее здание это не только не тру, но даже и не паранойя Обычная паранойя - это два ЦОД'а разнесенные не менее, чем на 100 км Тру-паранойя - это второй ЦОД в другой стране |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |