Serwer testowy z produkcji - praktycznie

[pabi]

Witam
Mam pytanie jak najszybciej, ale też całkowicie bezpiecznie można zrobić kopię serwera produkcyjnego na swój serwer taką piaskownicę do testów nazwijmy go KOSZ.
Czyli mam działajacy landscape dev, tst, prd i tutaj żadnego nie ruszam, natomiast tworzę sobie swój serwer do testów kosz całkowicie z boku i chcę na nim mieć kopię produkcji.

Ten mój serwer kosz musiałby mieć wyłączone wszystko, co identyfikowałoby go jako prd, ponieważ mój kosz ma się z niczym nie łączyć, nic nie odbierać ani nic nie wysyłać, ma to być tylko śmietnik to testów, jednak musi być tak ustawiony żeby nie zaburzył pracy obecnego landscape.

I teraz moje pytanie - jak to zrobić szybko ale bezpiecznie?

1.Najszybciej byłoby skopiować całą maszynę wirtualną PRD na nową maszynę wirtualną KOSZ, tylko co po takiej operacji musiałbym wyłaczyć w KOSZu , żeby nagle w sieci nie zaczęły być dwa serwery prd ? Procesy w tle, system rename konieczny ? , jakieś rfc wyłączyć, coś w gatewayu ?

2.Czy też od początku zainstalować serwer kosz i kopią mandanta zrzucić prd na kosz ?

Pytanie do praktyków.

[bjarkowski]

Niestety, nie ma jednej prawidlowej odpowiedzi. Moge sobie wyobrazic, ze masz w systemie raport Z, ktory bezposrednio laczy sie z serwerem pocztowym i wysyla maile - i jesli o nim nie wiesz, to mozesz go nie znalezc

Niemniej, co ja bym zrobil na Twoim miejscu, to skopiowal maszyne wirtualna i wrzucil ja do osobnej podsieci, bez dostepu do sieci lokalnej oraz internetu. Na firewall'u mozesz wyciac caly ruch z/do maszyny. Ustaw sobie bys jedynie Ty mogl sie z nia kontaktowac na wybanym porcie.
Nastepnie, zrob System Rename - mozesz wtedy zmienic hostname i system ID. Po wystartowaniu systemu sprawdzilbym konfiguracje poczty. W SM59 sprawdz wszystkie odwolania do innych systemu. Pewnie warto spojrzec na porty (WE21) jesli korzystasz z integracji.
Jesli chcesz taka prawidlowa kopie zrobic, to pewnie bym jeszcze BDLS odpalil aby zmienic system logiczny.

No i koniecznie poczytaj o system copy guide. To co napisalem powyzej jest bardzo skrotowe.
https://help.sap.com/viewer/30839dda13b ... 6c0b7.html

[tominek]

To jeszcze dwa słowa ode mnie, najlepiej pierwszy start zrobić bez aktywnych jobów BTC, wyłączając je w plikach profilu.

później żeby zabezpieczyć polaczenia RFC najlepiej jest zrobić update na tabeli RFCDES
w zależnosci od rodzaju bazy SELECT * from SAP<SID>.rfcdes, później update wszystkich z 3 na 2 i nic przez RFC nie wyjdzie, czy to IDOCKI, czy cokolwiek innego.
Pamiętałbym jeszcze o jobach:

Released -> Scheduled, kilka lat wstecz i do przodu, uwzględniając zdarzenia. Oraz usunął aktywne.

Pzdr,
T.

[pabi]

dzięki za pomoc
mam jeszcze jedno pytanie - w sumie to chyba byłoby skopiować maszynę wirtualną qas i potem zrobić kopię mandanta z prd , to chyba byłoby bezpieczniejsze niż kopia z prd ?

[bjarkowski]

A potrzebujesz produkcyjnych danych? Moze QA Ci wystarczy?

Moim zdaniem, jesli juz robisz kopie to klonuj PRD. Nie ma sensu sie potem bawic w kopie mandanta i robic obciazenie na produkcji. Choc tu pewnie ile osob tyle opinii.

Swoja droga nie macie zadnej dokumentacji na temat odswiezenia systemu QA? Zazwyczaj jest jakas dokumentacja ze wszystkimi wykonanymi krokami.

[jaroslaw.zdanowski]

Wszystko zawsze zależy od środowiska. Co do klona całej wirtualki produkcyjnej to kwestie są dwie:
1) Maszyna musi być wirtualizowana
2) Nie wszystkie bazy danych lubią się z takimi klonami (Tak, patrzę w tym momencie na Ciebie, MaxDB on Windows), szczególnie na Windows w AD.

W mojej opinii zawsze najlepszym sposobem jest połączenie tego co chłopaki napisali z metodą backup/restore.
Czyli:
1) Przygotowanie OS-a w osobnej podsieci, z wyciętym ruchem lokalnym z/i do internetu, etc. Najlepiej OS-a z tzw. golden/iron image, o ile coś takiego macie. Wtedy nie trzeba przygotowywać konfiguracji OS-a pod SAP.
2) Wykonanie System Copy z użyciem metody backup/restore.
3) Wykonanie wszystkich kroków post-copy, czyli m.in. joby, wszystkie integracje z systemami zewn., idoc'i, połączenia, ADS-y, etc. generalnie absolutnie wszystko co do tej pory się komunikowało z produkcją lub z czym się komunikowała produkcja. Im system większy i starszy tym zazwyczaj więcej integracji w środowisku.
4) Zmiana SID i najlepiej Virtual Hostname lub jej przypisanie.
5) Utworzenie nowych ścieżek transportowych, najlepiej nowej numeracji transportów, przekształcenie systemów źródłowych dla pakietów ABAP, etc.

To tak na szybko co mi przychodzi do głowy.

[pabi]

Jeszcze pytanie o bazę danych - baza danych jest na innym serwerze niż serwer aplikacyjny SAP.

Jak procedura wygląda wtedy ? Skopiujemy wirtualną maszynę serwera aplikacyjnego i na niej zrobimy system rename ale ciągle będzie się odwoływać do bazy danych prd. Pożądanym efektem końcowym jest otrzymanie nowego serwera aplikacyjnego KOSZ i bazy KOSZ, i nienaruszenie PRD AS i bazy.
Przed system rename stawiamy nową bazę KOSZ i robimy restore z bazy PRD ?
Sory jak niejasne ale już się zamieszałem.

[bjarkowski]

Najlepszym rozwiazaniem dla Ciebie bedzie wykonanie System Copy with Backup/Restore. Myslalem ze calosc masz na jednej VM'ce, dlatego pisalem wczesniej o kopii VM.

[pabi]

Podsumowując gdy serwer aplikacyjny i baza są na innych serwerach robimy najpierw backup restore bazy pod nowym Sid, a potem backup restore serwera aplikacyjnego pod nowym Sid. Dziękuję za pomoc.