Текущее время: Пт, апр 27 2018, 05:03

Часовой пояс: 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
Сообщения: 768
Пол: Мужской
Доброго дня! Вопрос к тем, кто виртуализировал 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
Сообщения: 2228
Откуда: Moscow, кажется...
Пол: Мужской
RikoNw написал:
Доброго дня! Вопрос к тем, кто виртуализировал SAP.
Размер VMDK диска под /oracle и /usr приближается к 2ТБ и тут вижу три варианта:

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

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

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

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

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


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

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


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

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

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

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


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

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

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


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

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

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


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


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

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


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

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

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


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

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


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

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


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

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

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


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

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


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

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

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

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

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


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

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

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

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


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

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

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

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

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


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

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

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

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


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

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

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