Witam
Następne pytanie do praktyków z serii instalacje SAPa, tym razem pytanie dotyczy SUSE i serii OSów SUSE for SAP Applications.
Bardzo słabo znam linuxa, więc pytanie może nie być najwyższych lotów .
Na stronie są wersje SUSE 12SP3 oraz 15.
Instalując 12SP3 widziałem, że instalator jest graficzny i system po instalacji też jest w wersji graficznej.
Czy instalujecie teraz nowe instalcje z tych instalatorów graficznych czy jednak wybieracie wersje bez elementów graficznych i skąd je bierzecie, bo na stronie producenta ich nie ma .
Przygotowanie OS - SUSE pod instalację SAPa
-
- Posty: 12
- Rejestracja: wt maja 08, 2018 3:40 pm
Re: Przygotowanie OS - SUSE pod instalację SAPa
Jeżeli tylko mam wybór pod instalację SAP to zawsze wybieram instalację bez Desktop Envoirment, czysta konsola po ssh.
Kiedyś jeszcze opłacało się instalować XServer, ale od kiedy SWPM i SUM jest w wersji HTML to też to traci na znaczeniu.
Jak zainstalujesz w wersji graficznej to wciąż możesz się podłączyć po ssh, ale DE zjada Ci zasoby w tle. A jak nie ma DE to zawsze kilka cykli procesora więcej dla SAP i bazy danych.
Kiedyś jeszcze opłacało się instalować XServer, ale od kiedy SWPM i SUM jest w wersji HTML to też to traci na znaczeniu.
Jak zainstalujesz w wersji graficznej to wciąż możesz się podłączyć po ssh, ale DE zjada Ci zasoby w tle. A jak nie ma DE to zawsze kilka cykli procesora więcej dla SAP i bazy danych.
Re: Przygotowanie OS - SUSE pod instalację SAPa
dzięki, o to mi chodziło
jeszcze pytanko o instalacje SAPa w High Avaibility.
Co tak naprawdę potem pracuje w hihh avaibility jak mamy Bazę, DVEMGSS00, D01,D02,D03 i ASCS01, czyli przykładowo baza , central instance, dwie dialogowe i jedna central service instance (ASCS).
Czy któryś element nie ejst high avaibility ? Jak stanie DVEMGS00 to D01 przejmie jego rolę czy system stanie.
jeszcze pytanko o instalacje SAPa w High Avaibility.
Co tak naprawdę potem pracuje w hihh avaibility jak mamy Bazę, DVEMGSS00, D01,D02,D03 i ASCS01, czyli przykładowo baza , central instance, dwie dialogowe i jedna central service instance (ASCS).
Czy któryś element nie ejst high avaibility ? Jak stanie DVEMGS00 to D01 przejmie jego rolę czy system stanie.
-
- Posty: 116
- Rejestracja: pt lip 15, 2016 5:31 pm
- Has thanked: 2 times
- Been thanked: 46 times
Re: Przygotowanie OS - SUSE pod instalację SAPa
Popieram to co napisal Jarek. Kiedys tez instalowalem GUI, teraz na to uwagi nie zwracam. Czasem trzeba tez cos z Download Managera sciagnac i GUI sie przydaje (wget czesto nie daje rady).
Re: Przygotowanie OS - SUSE pod instalację SAPa
i standardowo, ja dorzucę jeszcze od siebie dwa grosze
domyślam się że nie jesteś expertem linuxowym, także zakładam że niektóre rzeczy będzie Cie wygodniej zrobić z poziomu interfejsu graficznego, bo zanim się dogrzebiesz w jakich plikach, co konkretnie trzeba zrobić, ewentualnie jak działa VI, lub jakie są komendy systemowe to trochę potrwa.
Także na początek sugeruje jednak instalacje w wersji graficznej, a w ramach nauki korzystanie z putty i ssh.
HA jest wykorzystywane w rozwiązaniach klastrowych, dobrym przykładem jest np. klaster bazodanowy dla Hany w oparciu o SLES. Działa całkiem nieźle.
Pzdr,
T.
domyślam się że nie jesteś expertem linuxowym, także zakładam że niektóre rzeczy będzie Cie wygodniej zrobić z poziomu interfejsu graficznego, bo zanim się dogrzebiesz w jakich plikach, co konkretnie trzeba zrobić, ewentualnie jak działa VI, lub jakie są komendy systemowe to trochę potrwa.
Także na początek sugeruje jednak instalacje w wersji graficznej, a w ramach nauki korzystanie z putty i ssh.
HA jest wykorzystywane w rozwiązaniach klastrowych, dobrym przykładem jest np. klaster bazodanowy dla Hany w oparciu o SLES. Działa całkiem nieźle.
Pzdr,
T.
-
- Posty: 116
- Rejestracja: pt lip 15, 2016 5:31 pm
- Has thanked: 2 times
- Been thanked: 46 times
Re: Przygotowanie OS - SUSE pod instalację SAPa
Odnosnie HA pozwole sobie udostepnic kilka linkow do postow mojego autorstwa o HA:
https://blogs.sap.com/2017/11/14/your-s ... n-windows/
https://blogs.sap.com/2018/01/08/your-s ... plication/
https://blogs.sap.com/2018/03/07/your-s ... es-direct/
A tutaj jest jeszcze jeden fajny napisany przez kogos innego (w zasadzie powinienes tutaj zaczac i dopiero do moich postow przejsc):
https://blogs.sap.com/2016/08/05/high-a ... explained/
https://blogs.sap.com/2017/11/14/your-s ... n-windows/
https://blogs.sap.com/2018/01/08/your-s ... plication/
https://blogs.sap.com/2018/03/07/your-s ... es-direct/
A tutaj jest jeszcze jeden fajny napisany przez kogos innego (w zasadzie powinienes tutaj zaczac i dopiero do moich postow przejsc):
https://blogs.sap.com/2016/08/05/high-a ... explained/
Re: Przygotowanie OS - SUSE pod instalację SAPa
w takim razie pytanie ode mnie.
Korzystacie w praktyce z rozwiązań klastrowych dla serwerów aplikacyjnych SAPa, w oparciu o rozwiązania SUSE i replikacji blokad ? Jakie wrażenia ?
Warto implementować jako alternatywę dla CI/DI ?
Czy raczej opieracie się o Central Instance + Dialog Instance i do tego grupy logowania ?
Pzdr,
T.
Korzystacie w praktyce z rozwiązań klastrowych dla serwerów aplikacyjnych SAPa, w oparciu o rozwiązania SUSE i replikacji blokad ? Jakie wrażenia ?
Warto implementować jako alternatywę dla CI/DI ?
Czy raczej opieracie się o Central Instance + Dialog Instance i do tego grupy logowania ?
Pzdr,
T.
-
- Posty: 116
- Rejestracja: pt lip 15, 2016 5:31 pm
- Has thanked: 2 times
- Been thanked: 46 times
Re: Przygotowanie OS - SUSE pod instalację SAPa
Tominek: moglbys napisac kilka slow o tym rozwiazaniu SUSE?
Ja zazwyczaj staram sie nie korzystac z HA gdy nie musze. W przypadku DI sprawa jest prosta - wystarczy zainstalowac kilka serwerow aplikacji i zalatwione. W przypadku ASCS - tutaj juz jest trudniej i najczesciej ustawiam po prostu klon VM na osobnym serwerze, aby w razie awarii moc szybko wznowic prace. Moim zdaniem jest to zdecydowanie latwiejsze i tansze w zarzadzaniu. Oczywiscie wszystko zalezy od klienta - znam takich, gdzie HA musi byc i tyle, wtedy dodatkowy node dla ASCS.
Z bazami danych roznie, praktycznie kazda ma co najmniej 2-3 rozwiazania do budowy rozwiazan HA. W SAP HANA korzystam zazwyczaj z System Replication (bo to jest wspierane w Azure) plus automatyczny failover za pomoca pacemakera (choc wkurza mnie bardzo to rozwiazanie)
Moim zdaniem bardzo trudno zbudowac jest prawdziwe HA i klienci na ogol tego nie rozumieja. Potrafia wydac gore kasy na sprzet i konfiguracje, a na koncu zawiedzie jedyny router jaki maja w firmie
Ja zazwyczaj staram sie nie korzystac z HA gdy nie musze. W przypadku DI sprawa jest prosta - wystarczy zainstalowac kilka serwerow aplikacji i zalatwione. W przypadku ASCS - tutaj juz jest trudniej i najczesciej ustawiam po prostu klon VM na osobnym serwerze, aby w razie awarii moc szybko wznowic prace. Moim zdaniem jest to zdecydowanie latwiejsze i tansze w zarzadzaniu. Oczywiscie wszystko zalezy od klienta - znam takich, gdzie HA musi byc i tyle, wtedy dodatkowy node dla ASCS.
Z bazami danych roznie, praktycznie kazda ma co najmniej 2-3 rozwiazania do budowy rozwiazan HA. W SAP HANA korzystam zazwyczaj z System Replication (bo to jest wspierane w Azure) plus automatyczny failover za pomoca pacemakera (choc wkurza mnie bardzo to rozwiazanie)
Moim zdaniem bardzo trudno zbudowac jest prawdziwe HA i klienci na ogol tego nie rozumieja. Potrafia wydac gore kasy na sprzet i konfiguracje, a na koncu zawiedzie jedyny router jaki maja w firmie
Re: Przygotowanie OS - SUSE pod instalację SAPa
mam na myśli rozwiązanie z poniższego linka:
https://www.suse.com/media/white-paper/ ... _guide.pdf
Czyli klaster dla aplikacyjnych serwerów SAPowych, z replikacja blokad, w oparciu o OS - SLES12.
Ja generalnie mam bardzo pozytywne doświadczenia w oparciu o CI + kilka DI, a do tego klaster SUSE, oczywiście z replikacją HANA. W przypadku awarii jednego NODa klastra bazodanowego, automatycznie przełącza ruch na drugiego NODa i działa to całkiem nieźle.
Natomiast zastanawiam się nad zaletami klastra serwera aplikacyjnego SUSE (link), z tego co wyczytałem replikuje również blokady. W przypadku awarii jednej z maszyn klastra serwera aplikacyjnego, cały ruch jest automatycznie przejmowany przez kolejne NODy łącznie z blokadami, o ile dobrze zrozumiałem.
Stąd moje pytanie czy ktos to wykorzystuje w praktyce, oraz jakie są plusy/minusy.
Pzdr,T.
https://www.suse.com/media/white-paper/ ... _guide.pdf
Czyli klaster dla aplikacyjnych serwerów SAPowych, z replikacja blokad, w oparciu o OS - SLES12.
Ja generalnie mam bardzo pozytywne doświadczenia w oparciu o CI + kilka DI, a do tego klaster SUSE, oczywiście z replikacją HANA. W przypadku awarii jednego NODa klastra bazodanowego, automatycznie przełącza ruch na drugiego NODa i działa to całkiem nieźle.
Natomiast zastanawiam się nad zaletami klastra serwera aplikacyjnego SUSE (link), z tego co wyczytałem replikuje również blokady. W przypadku awarii jednej z maszyn klastra serwera aplikacyjnego, cały ruch jest automatycznie przejmowany przez kolejne NODy łącznie z blokadami, o ile dobrze zrozumiałem.
Stąd moje pytanie czy ktos to wykorzystuje w praktyce, oraz jakie są plusy/minusy.
Pzdr,T.
Re: Przygotowanie OS - SUSE pod instalację SAPa
Dzięki za metriały do HA, świetne.
BJARKOWSKI: "W przypadku ASCS - tutaj juz jest trudniej i najczesciej ustawiam po prostu klon VM na osobnym serwerze, aby w razie awarii moc szybko wznowic prace".
Rouzmiem, że jest to klon samego ASCS bez PAS. Zastanawia mnie jedno wg SAPa PAS jednak rózni się od AAS , to ciekawe czym się różni, bo jeżeli w przypadku awarii PAS każdy AAS go zastąpi i system działa, to te róznice nie mogą mieć zwiazku z funkcjami HA ?
BJARKOWSKI: "W przypadku ASCS - tutaj juz jest trudniej i najczesciej ustawiam po prostu klon VM na osobnym serwerze, aby w razie awarii moc szybko wznowic prace".
Rouzmiem, że jest to klon samego ASCS bez PAS. Zastanawia mnie jedno wg SAPa PAS jednak rózni się od AAS , to ciekawe czym się różni, bo jeżeli w przypadku awarii PAS każdy AAS go zastąpi i system działa, to te róznice nie mogą mieć zwiazku z funkcjami HA ?
-
- Posty: 116
- Rejestracja: pt lip 15, 2016 5:31 pm
- Has thanked: 2 times
- Been thanked: 46 times
Re: Przygotowanie OS - SUSE pod instalację SAPa
Zgodnie z SAP:
The Primary Application Server (PAS) is the application server that was first installed on the SAP system. All other application servers of an SAP system are called Additional Application Servers (AAS).
The following changes to architecture and terminology were introduced with SAP NetWeaver AS 7.10*:
● The former “central instance” was renamed as “Primary Application Server (PAS)”
● The former “dialog instance” was renamed as “Additional Application Server (AAS)”
Pod wzgledem technicznym PAS = AAS. Nie ma tam zadnej roznicy.
The Primary Application Server (PAS) is the application server that was first installed on the SAP system. All other application servers of an SAP system are called Additional Application Servers (AAS).
The following changes to architecture and terminology were introduced with SAP NetWeaver AS 7.10*:
● The former “central instance” was renamed as “Primary Application Server (PAS)”
● The former “dialog instance” was renamed as “Additional Application Server (AAS)”
Pod wzgledem technicznym PAS = AAS. Nie ma tam zadnej roznicy.
-
- Posty: 12
- Rejestracja: wt maja 08, 2018 3:40 pm
Re: Przygotowanie OS - SUSE pod instalację SAPa
Robiliśmy takie ropzwiązanie z wykorzystaniem 2-nodów ASCS+ ERS + PAS + AAS. Wszystko na różnych VM-kach.tominek pisze: ↑pn paź 08, 2018 12:09 pm mam na myśli rozwiązanie z poniższego linka:
https://www.suse.com/media/white-paper/ ... _guide.pdf
Czyli klaster dla aplikacyjnych serwerów SAPowych, z replikacja blokad, w oparciu o OS - SLES12.
Ja generalnie mam bardzo pozytywne doświadczenia w oparciu o CI + kilka DI, a do tego klaster SUSE, oczywiście z replikacją HANA. W przypadku awarii jednego NODa klastra bazodanowego, automatycznie przełącza ruch na drugiego NODa i działa to całkiem nieźle.
Natomiast zastanawiam się nad zaletami klastra serwera aplikacyjnego SUSE (link), z tego co wyczytałem replikuje również blokady. W przypadku awarii jednej z maszyn klastra serwera aplikacyjnego, cały ruch jest automatycznie przejmowany przez kolejne NODy łącznie z blokadami, o ile dobrze zrozumiałem.
Stąd moje pytanie czy ktos to wykorzystuje w praktyce, oraz jakie są plusy/minusy.
Pzdr,T.
Szczerze powiedziawszy to jest rozwiązanie, które dość trudno skonfigurować i przetestować. Najbardziej problematyczny jest ERS, bo w tym rozwiązaniu jest tak naprawdę najważniejszy.
Plusy:
-> Teoretycznie zapewnia całkowite bezpieczeństwo AS i spełania wymogi BCP.
-> Pozwala robić load balancing.
-> Teoretycznie wymaga relatywnie niewielkich zasobów (ASCS/ERS).
Minusy:
-> Relatywnie trudny w konfiguracji
-> Trudny w monitoringu
-> ERS potrafi robić problemy z lockami.
-> Ciężko znaleźć działające rozwiązanie.
Re: Przygotowanie OS - SUSE pod instalację SAPa
Dziei za odpowiedź, jeszcze kilka pytań uzupełniających.
- dlaczego ERS jest najbardziej problematyczny (ze względu na problemy z lockami), oraz dlaczego najważniejszy ?
O ile dobrze rozumiem to w przykładowym scenariuszu dwa NODy, ASCS + ERS, uniezależniamy się całkowicie od potencjalnych awarii jednego serwera aplikacyjnego, bo po to mamy dwa nody z replikacją locków, żeby każdy z nich mógł działać samodzielnie i nie trzeba było ni przełączać ręcznie.
Czy się myle ?
Pzdr,
T.
- dlaczego ERS jest najbardziej problematyczny (ze względu na problemy z lockami), oraz dlaczego najważniejszy ?
O ile dobrze rozumiem to w przykładowym scenariuszu dwa NODy, ASCS + ERS, uniezależniamy się całkowicie od potencjalnych awarii jednego serwera aplikacyjnego, bo po to mamy dwa nody z replikacją locków, żeby każdy z nich mógł działać samodzielnie i nie trzeba było ni przełączać ręcznie.
Czy się myle ?
Pzdr,
T.
-
- Posty: 116
- Rejestracja: pt lip 15, 2016 5:31 pm
- Has thanked: 2 times
- Been thanked: 46 times
Re: Przygotowanie OS - SUSE pod instalację SAPa
Dzieki za linka do dokumentacji. Przejrzalem dokument, nie wczytywalem sie jeszcze w szczegoly i wyglada to ciekawie. Musze to przetestowac - i bedzie okazja do bloga
W standardowym modelu jest tak jak piszesz.
@Jarek: a ile nodow ASCS mieliscie? Dwa? Active/Passive?
W standardowym modelu jest tak jak piszesz.
@Jarek: a ile nodow ASCS mieliscie? Dwa? Active/Passive?