Текущее время: Чт, дек 14 2017, 13:55

Часовой пояс: UTC + 4 часа


Правила форума


ВНИМАНИЕ! Прежде чем задавать вопрос, ознакомьтесь со ссылками ниже:

Вопросы по отличиям версий SAP, Add-On, EHP - сюда
Вопросы по SAP Front End (SAPlogon, SAPgui, guiXT и т.д.) - сюда
Вопросы по LSMW - сюда
Вопросы по архивации в SAP - сюда
Вопросы по SAP GRC - сюда
Вопросы по SAP Business Workplace (почте SAP) и SAP Office - сюда
Вопросы по miniSAP (SAP mini basis) - сюда
Вопросы по SAP HANA - сюда
Вопросы по лицензированию продуктов SAP - сюда



Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Вт, окт 03 2017, 15:06 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пн, янв 14 2013, 11:37
Сообщения: 728
Пол: Мужской
Доброго дня! Вопрос к тем, кто виртуализировал SAP.
Размер VMDK диска под /oracle и /usr приближается к 2ТБ и тут вижу три варианта:

- Расширить VMDK более 2 ТБ и потерять возможность storage vmotion
- Расширить VMDK более 2 ТБ с разбивкой VMDK по 2 ТБ и не потерять возможности storage vmotion
- Создать следующий VMDK и перенести туда, например, датафайлы базы

Есть ли какие-то еще варианты и какой более правильный по вашему мнению ? Спасибо.

з.ы. отказаться от виртуализации не предлагать, виртуализация рулит :D


Пометить тему как нерешенную
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Вт, окт 03 2017, 17:32 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 18:10
Сообщения: 2223
Откуда: Moscow, кажется...
Пол: Мужской
RikoNw писал(а):
Доброго дня! Вопрос к тем, кто виртуализировал SAP.
Размер VMDK диска под /oracle и /usr приближается к 2ТБ и тут вижу три варианта:

- Расширить VMDK более 2 ТБ и потерять возможность storage vmotion
- Расширить VMDK более 2 ТБ с разбивкой VMDK по 2 ТБ и не потерять возможности storage vmotion
- Создать следующий VMDK и перенести туда, например, датафайлы базы

Есть ли какие-то еще варианты и какой более правильный по вашему мнению ? Спасибо.

з.ы. отказаться от виртуализации не предлагать, виртуализация рулит :D

Добавить диск, положить на него датафайлы.
При этом не забыть диск зацепить за свой дисковый контроллер.
Оська какая стоит? А то для линухов под vmware в параметрах ядра надо несколько нужных вещей дописывать.

_________________
Если банахово пространство рефлексивно, то единичный шар слабо компактен! Точно знаю! (c) М.Королюк
BRGDS,
Aleks Изображение


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Ср, окт 04 2017, 14:00 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пн, янв 14 2013, 11:37
Сообщения: 728
Пол: Мужской
Да собственно говоря на системах и на Windows и на Linux потихоньку приближается порог.. А что это за параметры ядра такие ? Чего-то не слышал..


Пометить тему как нерешенную
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Ср, окт 04 2017, 14:15 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 18:10
Сообщения: 2223
Откуда: Moscow, кажется...
Пол: Мужской
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 свое есть :)
Ну а про остальное можно погуглить что и зачем :)

Кста, у винды обязательно схему питания поставить в режим производительности. Чтобы ядра спать не ходили.

_________________
Если банахово пространство рефлексивно, то единичный шар слабо компактен! Точно знаю! (c) М.Королюк
BRGDS,
Aleks Изображение


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Пн, окт 09 2017, 09:19 
Специалист
Специалист

Зарегистрирован:
Ср, янв 16 2013, 05:04
Сообщения: 157
RikoNw писал(а):
Есть ли какие-то еще варианты и какой более правильный по вашему мнению ?

лично я бы разбил систему на 2 части: ВМ под сервер с БД и ВМ под САП. Первое бэкапить/резервировать средствами СУБД онлайн, второе - загасил машинку с сапом, положил образ в сторонку и продолжаем. Если доверяете онлайновым вмваревым бэкапам то можно и ими.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Пн, окт 09 2017, 10:21 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пн, янв 14 2013, 11:37
Сообщения: 728
Пол: Мужской
sap2me писал(а):
RikoNw писал(а):
Есть ли какие-то еще варианты и какой более правильный по вашему мнению ?

лично я бы разбил систему на 2 части: ВМ под сервер с БД и ВМ под САП. Первое бэкапить/резервировать средствами СУБД онлайн, второе - загасил машинку с сапом, положил образ в сторонку и продолжаем. Если доверяете онлайновым вмваревым бэкапам то можно и ими.


Да, тоже вариант, только боюсь будет некоторая просадка производительности, ведь сервер СУБД и инстанция начнут общаться по сети, пусть и виртуальной..


Пометить тему как нерешенную
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Пн, окт 09 2017, 10:40 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 18:10
Сообщения: 2223
Откуда: Moscow, кажется...
Пол: Мужской
RikoNw писал(а):
sap2me писал(а):
лично я бы разбил систему на 2 части: ВМ под сервер с БД и ВМ под САП. Первое бэкапить/резервировать средствами СУБД онлайн, второе - загасил машинку с сапом, положил образ в сторонку и продолжаем. Если доверяете онлайновым вмваревым бэкапам то можно и ими.


Да, тоже вариант, только боюсь будет некоторая просадка производительности, ведь сервер СУБД и инстанция начнут общаться по сети, пусть и виртуальной..

У вас база, видимо, лежит на SSD? В любом другом случае надо очень постараться построить хранилище, которое умеет отдавать данные заметно быстрее гигабитной сетки. Это я к тому, что скорость до сих пор определяется скоростью работы СХД.
Если вы живете на одном хосте vmware и у вас хватает ресурсов (процессор/память) на обе виртуалки, то никакого кайфа от разделения не будет. Смысл в разделении есть исключительно, если на хосте уже нет свободных ресурсов а система хочет больше памяти. Тогда есть смысл в разделении. Но и то, гораздо проще на соседнем хосте поставить еще одну аппликуху, чем делить живую систему.
Просадкой производительности по сетке можно пренебречь :) Особенно если у вас хосты связаны по десятке. Да даже и гигабита хватает на достаточно большие базы. Скорость сетки будет определять исключительно время загрузки системы. Точнее даже не это, а скорость забития буферов на аппликухе данными из БД. А буфера забиваются очень даже постепенно.

_________________
Если банахово пространство рефлексивно, то единичный шар слабо компактен! Точно знаю! (c) М.Королюк
BRGDS,
Aleks Изображение


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Пн, окт 09 2017, 10:59 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пн, янв 14 2013, 11:37
Сообщения: 728
Пол: Мужской
30% SSD, комбинированная СХД, да, согласен, хоть сетью можно пренебречь, все же делить аппликуху и СУБД бессмысленно в моем случае. Остановился на диске E:\ для части датафайлов :D


Пометить тему как нерешенную
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Пн, окт 09 2017, 11:07 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пн, янв 14 2013, 11:37
Сообщения: 728
Пол: Мужской
avlag, а про логи базы на отдельном диске, вы имеете в виду оперативные логи или архивлоги? Я складываю архивлоги каждый час сразу на сетевой диск, чтобы если при самом плохом раскладе, даже если с сервером что-то случилось физически можно было докатить базу до последнего часа. Просто можно еще зеркало оперативных логов держать на другом хосте, но есть ли в этом смысл..


Пометить тему как нерешенную
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.  Тема решена
СообщениеДобавлено: Пн, окт 09 2017, 11:43 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 18:10
Сообщения: 2223
Откуда: Moscow, кажется...
Пол: Мужской
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.

_________________
Если банахово пространство рефлексивно, то единичный шар слабо компактен! Точно знаю! (c) М.Королюк
BRGDS,
Aleks Изображение


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Пн, окт 09 2017, 12:05 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Пн, янв 14 2013, 11:37
Сообщения: 728
Пол: Мужской
У меня просто режим паранойи, архивлоги держу на случай попадания метеорита прямо в СХД :D Ну или на случай повреждения VMDK. Психологически не могу пока принять мысль о локальном хранении, но попробую :pivo:
Да, если это будут отдельные vmdk будет лучше, например, диск с архивлогами можно реплицировать средствами Veeam.
А так да, ночью, когда база переходит в backup mode, иногда, случается ситуация ожидания записи архивлога по сети, ведь база все изменения начинает хранить в оперативных журналах и архивлогах, дабы датафайлы оставались консистентными на момент их бэкапа.


Пометить тему как нерешенную
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Пн, окт 09 2017, 12:41 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 18:10
Сообщения: 2223
Откуда: Moscow, кажется...
Пол: Мужской
RikoNw писал(а):
У меня просто режим паранойи, архивлоги держу на случай попадания метеорита прямо в СХД :D Ну или на случай повреждения VMDK. Психологически не могу пока принять мысль о локальном хранении, но попробую :pivo:

Чтобы режим паранойи стал менее назойливым надо вторую СХД в соседнем ЦОД'е, на расстоянии не менее 100 км от первого, и реплицироваться средствами СХД. :D
Ну и кластерок там же вмварьный, с готовой инфраструктурой по поднятию системы, навернувшейся в первом ЦОД'е...
А если по жизни, то первым шагом с бизнеса надо стребовать допустимое время простоя при попадании метеорита, т.е. время на дизастер рекавери, и допустимый объем потерянных данных, которые могут возникнуть при переезде в другой ЦОД.
После этого посчитать, сколько это будет стоить и, постепенно, уменьшая стоимость и увеличивая время, прийти к консенсусу :)
Цитата:
Да, если это будут отдельные vmdk будет лучше, например, диск с архивлогами можно реплицировать средствами Veeam.
А так да, ночью, когда база переходит в backup mode, иногда, случается ситуация ожидания записи архивлога по сети, ведь база все изменения начинает хранить в оперативных журналах и архивлогах, дабы датафайлы оставались консистентными на момент их бэкапа.

А вообще сейчас интересно все начинает складываться. После построения полноценной отказоустойчивой системы внезапно приходит понимание, что архайвлоги нужны исключительно при восстановлении системы из бэкапа на определенный момент времени. А после этого возникает крамольная мысль (если система живет в распределенном кластере), а на кой ляд нужны бэкапы? На случай, если дизастер пришел сразу в два ЦОДа? :roll: Придется наращивать группировку! А бэкапы, тогда, делать еще и в четвертое место, да еще и ежедневную выносную копию бэкапов (кстати вимом хорошо организовывается :))! Но тут перед глазами встает картинка с героической фигуркой админа, ползущего по развалинам с дисками выносного бэкапа в сторону квартиры вышестоящего руководства с вопросом на устах: - Куда ставить-то?!

_________________
Если банахово пространство рефлексивно, то единичный шар слабо компактен! Точно знаю! (c) М.Королюк
BRGDS,
Aleks Изображение


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Вт, окт 10 2017, 04:11 
Специалист
Специалист

Зарегистрирован:
Ср, янв 16 2013, 05:04
Сообщения: 157
avlag писал(а):
Если вы живете на одном хосте vmware и у вас хватает ресурсов (процессор/память) на обе виртуалки, то никакого кайфа от разделения не будет. Смысл в разделении есть исключительно, если на хосте уже нет свободных ресурсов а система хочет больше памяти. Тогда есть смысл в разделении. Но и то, гораздо проще на соседнем хосте поставить еще одну аппликуху, чем делить живую систему.

чет мне кажется в мире не так много товарищей которым проще рядом поставить второй апликэйшен сервер чем перенести виртуалку на другой хост в пуле серверов vmware. ;)

А кайф в том что оракл резервируется и бэкапится средствами оракла, а виртуалка с саповым каким-нибудь PI относительно статична и достаточно закопировать ВМ в сторонку пару раз в год. А потом развернуть ее быстро и почти где угодно потому что внутри нет многотерабайтной БД. И голова не болит что чего то из /etc или /usr/local/bin забыл скопировать.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Вт, окт 10 2017, 04:20 
Специалист
Специалист

Зарегистрирован:
Ср, янв 16 2013, 05:04
Сообщения: 157
RikoNw писал(а):
У меня просто режим паранойи, архивлоги держу на случай попадания метеорита прямо в СХД :D Ну или на случай повреждения VMDK. Психологически не могу пока принять мысль о локальном хранении, но попробую

главное средство от паранойи это стэндбай. если у вас его до сих пор нет ,то я надеюсь вы сказали начальству сколько у вас будет простой в случае если сдохнет железяка и вы начнете разворачивать вашу многотерабйтную БД. При том что у вас вообще есть где разворачивать ;)

копировать диск с архивлогами мне кажется излишним.

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


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: SAP on VmWare. Как преодолеть порог в 2ТБ.
СообщениеДобавлено: Вт, окт 10 2017, 08:33 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 18:10
Сообщения: 2223
Откуда: Moscow, кажется...
Пол: Мужской
sap2me писал(а):
Для тру параноиков есть стэндбай с передачей и накатом логов в соседнее здание. И настраивается еще одна БД(любая) которая так же принимает логи и складирует их куда-то, но находится она в третьем здании(соседнем городе, если каналы позволяют) и не обязана быть такой же большой как продуктив.

Соседнее здание это не только не тру, но даже и не паранойя :lol:
Обычная паранойя - это два ЦОД'а разнесенные не менее, чем на 100 км
Тру-паранойя - это второй ЦОД в другой стране ;)

_________________
Если банахово пространство рефлексивно, то единичный шар слабо компактен! Точно знаю! (c) М.Королюк
BRGDS,
Aleks Изображение


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 4 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Sampoi и гости: 13


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB