Wsparcie Techniczne
Architektura SAS 9
Najczęstsze problemy i pytania związane z architekturą SAS® Intelligence Platform
Dowiedz się więcej na temat pracy z architekturą metadanych oraz serwerami aplikacji.
- Serwer metadanych
- Object Spawner
- Workspace Serwer
- Stored Process Serwer
- Pooled Workspace Serwer
- OLAP Serwer
Jak uruchomić serwer metadanych?
UNIX
Sugerowaną metodą jest wykorzystanie skryptu (<sas_config>/Levx/sas.servers), który służy do uruchamiania i zatrzymywania wszystkich procesów środowiska działających na danej maszynie w odpowiedniej kolejności.
Uruchomienie: ./sas.servers start
Zatrzymanie: ./sas.servers stop
Każdy z procesów można również wystartować ręcznie. Dla serwera metadanych skrypt startujący znajduje się w katalogu serwera (/Levx/SASMeta/MetadataServer).
Uruchomienie serwera: ./MetadataServer.sh start
Zatrzymanie serwera: ./MetadataServer.sh stop
Windows
Na Windows najczęściej procesy działające w ramach środowiska SAS są zainstalowane jako usługi. Wystarczy więc w oknie Usług uruchomić proces o domyślnej nazwie SAS [nazwa_katalogu-Levx] SASMeta - Metadata Server. Skrót do skryptu startującego serwera metadanych może być również dostępny w menu Start -> Programy -> SAS. Sam skrypt znajduje się w katalogu serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer).
Uruchomienie serwera: MetadataServer.bat start
Zatrzymanie serwera: MetadataServer.bat stop
Jak sprawdzić czy serwer metadanych działa?
UNIX
Do sprawdzenia, czy serwer metadanych działa można wykorzystać skrypt startujący i zatrzymujący wszystkie procesy środowiska SAS (<sasconfig>/Levx/sas.servers):./sas.servers status
Można również wykorzystać skrypt z katalogu serwera metadanych (<sasconfig>/Lev/SASMeta/MetadataServer): ./MetadataServer.sh status
Windows
Jeżeli serwer metadanych działa jako usługa, status serwera wystarczy sprawdzić w oknie Usług. Innym sposobem jest wykorzystanie skryptu z katalogu serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer):
MetadataServer.bat status
Na obu platformach można również wykorzystać procedurę METAOPERATE, uruchamiając ją bezpośrednio z SASa (SAS Foundation nie musi być uruchomione na tej samej maszynie co serwer metadanych):
PROC METAOPERATE SERVER="host-name"
PORT= port-number
USERID= "userid"
PASSWORD="password"
ACTION=STATUS;
RUN;<
Jak sprawdzić czy na danym koncie startuje proces SAS?
W celu sprawdzenia, czy SAS startuje na danym koncie, należy zalogować się na konto tego użytkownika i uruchomić SASa z katalogu instalacyjnego <sashome>\SASFoundation\9.4\sas.exe lub <sashome>/SASFoundation/9.4/sas.
UNIX
Do przelogowania na innego użytkownika można wykorzystać polecenie
su nazwa_użytkownika
Windows
SASa można uruchomić w imieniu innego użytkownika za pomocą polecenie runas: runas /user:nazwa_użytkownika <sashome>\SASFoundation\9.4\sas.exe
Jak zaktualizować licencję SAS?
Po wygaśnięciu licencji SAS przestaje działać. Wszystkie informacje o licencjach, w tym kroki, które należy wykonać przy aktualizacji licencji, znajdują się na stronach License Assistance
Jakie pliki konfiguracyjne są wykorzystywane przy uruchomieniu serwera metadanych?
Serwer metadanych korzysta z plików konfiguracyjnych, które znajdują się w katalogu serwera metadanych (<sasconfig>/Levx/SASMeta/MetadataServer) oraz z plików konfiguracyjnych znajdujących się w katalogu instalacyjnym SAS Foundation. Pliki konfiguracyjne w katalogu serwera metadanych:
- adminUsers.txt - zawiera informacje o specjalnych użytkownikach w metadanych - administratorach i użytkownikach 'unrestricted'
- logconfig.xml - definiuje mechanizm logowania dla serwera metadanych
- omaconfig.xml - podstawowe opcje do uruchomienia serwera metadanych
- trustedUsers.txt - informacje o użytkownikach specjalnych w metadanych (uwierzytelnionych)
- trustedPeers.xml - informacje o specjalnych połączeniach z serwerem metadanych
- sasv9.cfg - plik konfiguracyjny SAS, ze specjalnymi opcjami dla serwera metadanych
- sasv9_usermods.cfg - plik konfiguracyjny SAS z dodatkowymi opcjami; wszelkie modyfikacje podstawowych ustawień powinny być wprowadzane w tym pliku.
Dodatkowo wykorzystywane są wszystkie pliki konfiguracyjne używane przy starcie sesji SAS (punkt 6).
Jakie uprawnienia musi mieć użytkownik w systemie operacyjnym, żeby wystartowac proces SAS?
Użytkownik musi mieć dostęp:
- do odczytu do katalogu, w którym jest zainstalowane SAS Foundation (<sashome>/SASFoundation/9.4) oraz do podkatalogów.
- do uruchamiania komendy startującej SASa (linku sas na UNIX lub polecenia sas.exe w katalogu SAS Foundation). Na platformie UNIX może być zdefiniowany inny link.
UNIX
SAS jest uruchamiany za pomocą skryptu z katalogu <sashome>/SASFoundation/9.4/bin. W katalogu tym może znajdować się kilka skryptów, po jednym dla każdej wersji językowej, która jest zainstalowana. Pliki konfiguracyjne wykorzystywane przy starcie:
- <sashome>/SASFoundation/9.4/sasv9.cfg
- <sashome>/SASFoundation/9.4/nls//sasv9.cfg
- <sashome>/SASFoundation/9.4/sasv9_local
- sasv9.cfg w katalogu domowym użytkownika
W przypadku, gdy ta sama opcja jest ustawiana w kilku plikach, decydująca jest ostatnia napotkana definicja.
Wykorzystywane są również dwa pliki, które zawierają definicje zmiennych środowiskowych:
- <sashome>/SASFoundation/9.4/bin/sasenv
- <sashome>/SASFoundation/9.4/bin/sasenv_local - zawiera zmienne środowiskowe dodane przez administratora; przykładowo tutaj powinny być umieszczane zmienne środowiskowe niezbędne do skonfigurowania modułów SAS/ACCESS
Windows
Dodatkowo wykorzystywany jest plik \SASFoundation\9.4\sasv9.cfg, w którym znajduje się wskazanie na plik konfiguracyjny z katalogu \SASFoundation\9.4\nls\.
Obie platformy
Do działania SASa niezbędne są 3 biblioteki. Ich definicje znajdują się w plikach konfiguracyjnych lub w instrukcji uruchamiającej SAS:
- SASHELP - jest to konkatenacja kilku katalogów (podkatalogów katalogu instalacyjnego SAS), do których użytkownik musi mieć dostęp do odczytu.
- SASUSER - domyślnie wskazuje na katalog domowy użytkownika, choć w przypadku serwerów działających w środowisku SAS, mogą być zdefiniowane inne katalogi; dostęp może być tylko do odczytu
- WORK - biblioteka robocza, dostęp do modyfikacji.
Jakie uprawnienia w systemie operacyjnyum powienien mieć kazdy użytkwonik, na którego koncie startuje serwer metadanych?
UNIX
Serwer metadanych najczęściej startuje na koncie SAS Installer (domyślnie sas). SAS Deployment Wizard w trakcie instalacji i konfiguracji przypisuje temu użytkownikowi odpowiednie uprawnienia do katalogów i skryptów. Serwer metadanych nie powinien być startowany na koncie root.
Windows
Domyślnie serwer metadanych jest instalowany jako usługa i startuje na koncie SYSTEM, dzięki czemu ma odpowiednie uprawnienia. Jeżeli do uruchomienia serwera metadanych będzie wykorzystany inny użytkownik, należy zdefiniować dla niego odpowiednie uprawnienia do katalogów serwera metadanych. Użytkownik, na którym działa serwer metadanych powinien mieć pełne uprawnienia do następujących katalogów:
- <sasconfig>\Levx
- <sasconfig>\Levx\SASMeta
- <sasconfig>\Levx\SASMeta\MetadataServer
- <sasconfig>\Levx\SASMeta\MetadataServer\MetadataRepositories (a także do wszystkich katalogów, w których zostały zdefiniowane repozytoria, o ile znajdują się w niestandardowych miejscach).
- <sasconfig>\Levx\SASMeta\MetadataServer\rposmgr
Użytkownik musi mieć również prawo do odczytu i zapisu w katalogu, w którym tworzony jest log serwera metadanych (punkt 8).
Dodatkowo użytkownik musi mieć uprawnienia do wystartowania SASa (punkt 6).
Biblioteka SASUSER dla serwera metadanych jest definiowana w configu serwera metadanych jako tylko do odczytu i wskazuje na \Levx\SASMeta\MetadataServer\sasuser.
Uprawnienia, które powinny być zdefiniowane dla katalogu środowiska są opisane w dokumentacji w rozdziałach Recommended Operating System Protections for Windows Machines oraz Default Operating System Protections for UNIX and z/OS Machines.
Gdzie znaleźć log serwera metadanych?
Położenie logu jest zdefiniowane w pliku konfiguracyjnym <sasconfig>\Levx\SASMeta\MetadataServer\logconfig.xml. Domyślnie jest on tworzony w katalogu <sasconfig>\Levx\SASMeta\MetadataServer\Logs lub <sasconfig>\Levx\Logs.
UNIX
Na systemach UNIX oprócz standardowego logu, tworzony jest również dodatkowo SASMeta_MetadataServer_console.log. Lokalizacja tego pliku definiowana jest w skrypcie startującym serwer metadanych (<sasconfig>/Levx/SASMeta/MetadataServer/MetadataServer.sh)
W jaki sposób podaje się identyfikator użytkownika przy logowaniu?
Numer portu, na którym działa serwer metadanych powinien znajdować się w dokumentacji instalacyjnej. Można go również znaleźć w plikach konfiguracyjnych serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer\sasv9.cfg w ramach opcji objectserverparms).
Sprawdzanie, czy port jest zajęty można wykonać za pomocą polecenia netstat.
W jaki sposób podaje się identyfikator użytkownika przy logowaniu?
W celu korzystania z metadanych i pozostałych serwerów dostępnych w środowisku, użytkownik musi zalogować się do serwera metadanych. Serwer metadanych otrzymany identyfikator i hasło użytkownika prześle do autentykacji do odpowiedniego mechanizmu zewnętrznego. W niektórych przypadkach może przeprowadzić autentykację sam. Otrzymany identyfikator użytkownika zostanie też wykorzystany do identyfikacji użytkownika w metadanych.
Windows
Najczęściej na Windows zdefiniowana jest autentykacja domenowa. Wówczas przy logowaniu do serwera metadanych należy wpisać domena\identyfikator. Taki też identyfikator powinien być wpisany jako Login w definicji użytkownika. Jeżeli wykorzystywana jest autentykacja przez system operacyjny przy logowaniu wystarczy podać identyfikator użytkownika, natomiast w loginie identyfikator musi być poprzedzony nazwą serwera (np. server\sasdemo). Autentykacja zewnętrzna, niezależna od autentykacji domenowej zdefiniowanej dla systemu Windows, opisana jest w punkcie (punkt 11).
UNIX
Jeżeli wykorzystywana jest autentykacja poprzez system operacyjny, wówczas przy logowaniu użytkownik podaje swój identyfikator. W loginie również umieszcza się identyfikator użytkownika. Autentykacja zewnętrzna opisana jest w punkcie (punkt 11).
Na obu platformach można wykorzystywać konta wewnętrzne dla użytkowników, którzy wykonują wyłącznie zadania w obrębie serwera metadanych (nie uruchamiają żadnych procesów). Identyfikator takiego użytkownika to nazwa_użytkownika@saspw.
Inną możliwością jest skorzystanie z mechanizmu IWA - Integrated Windows Authentication. Dla serwera metadanych na Windows mechanizm ten jest domyślnie skonfigurowany. W przypadku UNIXa mechanizm wymaga zainstalowania i skonfigurowania dodatkowego narzędzia Quest Authentication Services. W takim przypadku identyfikator użytkownika jest odczytywany z systemu operacyjnego.
Większość aplikacji wykorzystuje profile, które przechowywane są na lokalnych komputerach. Zawierają one informacje, jak połączyć się z serwerem metadanych. Mogą mieć zapisany identyfikator i hasło użytkownika (hasło zakodowane). W przypadku problemów z zalogowaniem się dobrze jest sprawdzić profil, czy zawiera poprawny identyfikator i aktualne hasło.
Czy mozna zdefiniować inny sposób autentyfikacji niż system operacyjny dla serwera metadanych?
Domyślnie serwer metadanych autentykuje w oparciu o system operacyjny. Jeżeli do autentykacji ma być wykorzystane AD lub LDAP sugerowanym rozwiązaniem jest skonfigurowanie systemu operacyjnego tak, aby to on autentykował przez AD lub LDAP. Wtedy z tego sposobu autentykacji SAS będzie korzystał domyœlnie i żadne modyfikacje w środowisku SAS nie są konieczne. Można jednak skonfigurować dla serwera metadanych autentykację przez AD lub LDAP niezależnie od ustawień w systemie operacyjnym. W tym celu w pliku konfiguracyjnym serwera metadanych (<sasconfig>\Levx\SASMeta\MetadataServer\sasv9_usermods.cfg) należy dopisać opcję:
-authproviderdomain provider:authdomain | (provider-1:domain-1)
gdzie provider może przyjmować następujące wartości:
- ADIR autentykacja będzie przeprowadzana w oparciu o Active Directory
- HOSTUSER autentykacja będzie wykonywana w oparciu o system operacyjny; w tej opcji można podać domenę Windows
- LDAP autentykacja będzie wykonywana przez serwer LDAP
a authdomain to dowolna nazwa, która będzie używana przy logowaniu do wyboru rodzaju autentykacji. W takim przypadku przy logowaniu użytkownik powinien podać swój identyfikator w postaci identyfikator@authdomain chyba, że dodatkowo zostanie w pliku konfiguracyjnym zdefiniowana opcja
-PRIMARYPROVIDERDOMAIN
która pozwala zdefiniować jaki rodzaj autentykacji będzie domyślny. Wtedy podawanie domeny przy logowaniu do domyślnej domeny nie jest konieczne, natomiast przy logowaniu użytkowników hostowych należy logować się poprzez identyfikator@host.
Dodatkowo w celu wykorzystania tego sposobu autentykacji w systemie operacyjnym muszą być zdefiniowane zmienne środowiskowe, które pozwolą na połączenie się z AD lub LDAP. Szczegóły można znaleźć w SAS® 9.4 Intelligence Platform: Security Administration Guide.
Jak zmienić hasła użytkownikom technicznym (SASADM, SASTRUST, SASSRV)?
Użytkownicy techniczni to użytkownicy zdefiniowani w trakcie konfiguracji systemu, wykorzystywani do wykonywania pewnych standardowych funkcji w środowisku metadanych. Hasła dla nich mogą być zapisane w metadanych, mogą być również zapisane w plikach konfiguracyjnych. Do zmiany haseł dla tych użytkowników służy SAS Deployment Manager (<sashome>\SASDeploymentManager\9.4\sasdm.exe lub <sashome>/SASDeploymentManager/9.4/sasdm.sh). Za jego pomocą hasła zostaną zmienione zarówno w metadanych, jak i w odpowiednich plikach konfiguracyjnych.
Masz inne pytania?
Jaka jest kolejność startowania procesów w środowisku SAS 9.4?
Procesy należy startować w następującej kolejności:
Serwer lub proces | Warstwa | Zależność od innego procesu |
SAS Web Infrastructure Platform Data Server | Server tier | |
SAS Metadata Server | Server tier | |
SAS OLAP Server | Server tier | SAS Metadata Server |
SAS object spawner | Server tier | SAS Metadata Server |
SAS/SHARE server | Server tier | SAS Metadata Server |
SAS/CONNECT spawner | Server tier | SAS Metadata Server |
SAS Distributed In-Process Scheduler Job Runner | Server tier | SAS Metadata Server |
JMS Broker | Middle tier | |
Cache Locator | Middle tier | |
SAS Web Server | Middle tier | |
SAS Web Application Server | Middle tier | Cache Locator |
SAS Environment Manager server | Middle tier | SAS Web Infrastructure Platform Data Server SAS Web Application Server |
SAS Environment Manager Agent | Server middle tier | |
SAS Deployment Agent | Server middle tier |
Jak odblokować zablokowane konto użytkownika wewnętrznego w metadanych?
Domyślnie konto użytkownika wewnętrznego w metadanych jest zablokowanych po 3 kolejnych nieudanych próbach zalogowania. Odblokować konto może użytkownik unrestricted lub użytkownik, który należy do roli pozwalającej na zarządzanie użytownikami. Taki użytkownik powinien zalogować się do SAS Management Console i wyświetlić zakładkę Accounts we właściwościach zablokowanego użytkownika. Pojawi się wtedy pytanie o odblokowanie konta.
Jeżeli taki użytkownik nie jest dostępny, wówczas należy zmodyfikować plik konfiguracyjny serwera metadanych AdminUser.txt poprzez dopisanie identyfikatora użytkownika poprzedzając go '*', definiując w ten sposób nowego użytkownika unrestricted, i zrestartować serwer metadanych.
Uwaga! Restart serwera metadanych wymaga restartu wszystkich pozostałych procesów.
Używając dodanego konta zalogować się do SAS Management Console i odblokować zablokowane konto. Nastęnie usunąć identyfikator użytkownika z pliku AdminUsers.txt i zrestartować ponownie serwer metadanych.
Czy dla istniejącego środowiska mogę skonfigurować klaster serwera metadanych?
Tak. Klaster serwera metadanych można zdefiniować przy inicjalnym konfigurowaniu nowego środowiska, podczas migracji, jak również dla działającego serwera metadanych. Wymagania dla klastra serwera metadanych oraz kroki konfiguracyjne sa opisane w SAS 9.4 Intelligence Platform: System Administration Guide.
Jak zmodyfikowac profile połaczeniowe serwerów po skonfigurowaniu klastra serwera metadanych?
Serwery SAS korzystają z informacji zawartych w plikach konfiguracyjnych metadataConfig.xml w celu połączenia się z serwerem metadanych. Po skonfigurowaniu klastra serwera metadanych, jak również po modyfikacji konfiguracji, należy informacje zawarte w tych plikach zaktualizować.
Służy do tego narzędzie sas-update-metadata-profile zainstalowane w katalogu <SASHome>/SASPlatformObjectFramework/9.4/tools/admin. Powinno być uruchomione na każdej maszynie, na której działa object spawner, SAS/CONNECT spawner, workspace serwer, pooled workspace serwer, serwer OLAP i stored process serwer.
Gdzie znajdę dodatkowe informacje na temat administarcji środowiskiem SAS 9.4?
Dodatkowe informacje na temat administracji środowiskiem SAS można znaleźć w dokumentacji zebranej na stronie SAS Intelligence Platform.
Jak uruchomić object spawner?
Object spawner zaraz po starcie łączy się z serwerem metadanych i odczytuje stamtąd informacje niezbędne do działania. Dlatego ważne jest, aby został uruchomiony po starcie serwera metadanych.
UNIX
Sugerowaną metodą uruchomienia object spawnera jest wykorzystanie skryptu <sasconfig>/Levx/sas.servers. Skrypt ten startuje wszystkie procesy środowiska działające na danej maszynie w odpowiedniej kolejności. Możliwe jest również wystartowanie samego object spawnera za pomocą skryptu dostępnego w katalogu object spawnera:
<sasconfig>/Levx/ObjectSpawner/ObjectSpawner.sh start
Windows
Najczęściej object spawner jest zdefiniowany jako usługa (domyślna nazwa: 'SAS [nazwa_katalogu - Levx] Object Spawner'), więc uruchomienie go polega na uruchomieniu odpowiedniej usługi. Innym sposobem jest skorzystanie ze skrótu dostępnego w Start -> Programy-> SAS (o ile został dodany) lub ze skryptu znajdującego się w katalogu object spawnera:
<sasconfig>\Levx\ObjectSpawner\ObjectSpawner.bat start
Jak sprawdzić, czy object spawner działa?
UNIX
Do sprawdzenia statusu object spawnera można wykorzystać skrypt z katalogu <sasconfig>/Levx:
./sas.servers status
Pokaże on status wszystkich procesów środowiska SAS działającyh na danej maszynie. Można również wykorzystać skrypt dostępny w katalogu object spawnera (<sasconfig>/Levx/ObjectSpawner):
./ObjectSpawner.sh status
Windows
Jeżeli object spawner działa jako usługa, wystarczy sprawdzić status usługi. Można również wykorzystać skrypt znajdujący się w katalogu object spawnera <sasconfig>\Levx\ObjectSpawner:
ObjectSpawner.bat status
Jakie pliki konfiguracyjne są wykorzystywanie przez object spawner?
Object spawner korzysta z 2 plików konfiguracyjnych:
- metadataConfig.xml - plik zawiera parametry niezbędne do połączenia się z serwerem metadanych - nazwa/IP serwera, numer portu, identyfikator i hasło użytkownika, za pomocą którego object spawner będzie łączył się z serwerem metadanych; hasło w pliku jest zaszyfrowane. W celu sprawdzenia, czy hasło jest poprawne, można wykorzystać proc PWENCODE, która szyfruje hasła:
proc pwencode in="hasło";
run; - logconfig.xml - informacje o inicjalnym logowaniu ustawionym dla object spawnera.
Gdzie znaleźć log object spawnera?
Domyślnie object spawner tworzy codziennie nowy log. Wszystkie są umieszczane w katalogu <sasconfig>/Levx/ObjectSpawner/logs lub <sasconfig>/Levx/logs. Lokalizacja definiowana jest w pliku konfiguracyjnym logconfig.xml.
UNIX
Object spawner domyślnie tworzy dodatkowy log ObjectSpawner_console.log. Ten log jest ustawiany w skrypcie startującym object spawner (<sasconfig>/Levx/ObjectSpawner/ObjectSpawner.sh).
Jakie uprawnienia powinien mieć użytkownik, na którym działa object spawner?
UNIX
Domyślnie object spawner działa na koncie użytkownika SAS Installer. SAS Deployment Manager przy instalacji i konfiguracji środowiska przypisuje temu użytkownikowi odpowiednie uprawnienia. W przypadku wykorzystania innego konta trzeba zagwarantować, że użytkownik będzie miał dostęp do odczytu i zapisu do katalogu object spawnera (<sasconfig>/Levx/ObjectSpawner) oraz do katalogu, w którym będzie zapisywany log object spawnera (punkt 5).
Dodatkowo powinien mieć uprawnienia do uruchamiania <sasconfig>/Levx/ObjectSpawner/ObjectSpawner.sh i <sashome>/SASFoundation/9.4/utilities/bin/objspawn.
Windows
Domyślnie object spawner działa jako usługa uruchamiana na koncie SYSTEM. W takim przypadku żadne dodatkowe ustawienia nie są konieczne. Jeżeli będzie działać na innym koncie, wówczas należy zagwarantować, że wykorzystywany użytkownik będzie miał pełny dostęp do katalogu object spawnera (<sasconfig>\Levx\ObjectSpawner) oraz katalogu, w którym tworzony jest log object spawnera (punkt 5). Musi mieć również dostęp do katalogu <sashome>\SASFoundation\9.4.
Dodatkowo w systemie operacyjnym użytkownik powinien być członkiem grupy administratorów oraz mieć ustawione następujące uprawnienia:
- Dostosuj przydziały pamięci dla procesów (Adjust memory quotas for a process)
- Zamień żeton na poziomie procesu (replace a process level token)
W przypadku, kiedy workspace serwer został skonfigurowany tak, żeby wykorzystywał Integrated Windows Authentication (IWA) i ma dostawać się do serwisów sieciowych (np. bazy danych SQL Server lub do systemu plików z wykorzystaniem ścieżki UNC) korzystając z identyfikatora Windows to konto, na którym działa object spawner, potrzebuje jeszcze uprawnienia Trusted for Delegation.
Obie platformy
Oprócz użytkownika, na którego koncie działa object spawner, wykorzystywany jest również użytkownik do połączenia z metadanymi. Jest on potrzebny do odczytania definicji serwerów, które object spawner ma uruchamiać i loginów, które będą wykorzystywane do uruchamiania niektórych procesów. Może to być użytkownik wewnętrzny (domyślnie jest to SAS Trusted User). Wykorzystywany użytkownik jest zapisany w pliku konfiguracyjnym <sasconfig>/Levx/ObjectSpawner/metadataConfig.xml. Użytkownik ten musi mieć dostęp do definicji wszystkich serwerów uruchamianych przez dany object spawner w metadanych. Domyślnie SAS Trusted User należy do grupy SAS System Services, która ma dostęp do definicji wszystkich serwerów. Użytkownik musi również mieć dostęp do loginu (ów), na którym będą startowane stored process serwer, pooled workspace serwer i workspace serwer o ile został skonfigurowany do autentykacji tokenowej. Domyślnie SAS Trusted User należy do grupy SAS General Servers, do której został przypisany login, na którym działają stored process serwer i pooled workspace serwer.
Użytkownik, na którym działa object spawner nie powinien być użytkownikiem "unrestricted".
Na jakim porcie nasłuchuje object spawner?
Porty, na których nasłuchuje object spawner, są zapisane w metadanych. Object spawner wykorzystuje port operatora, który jest dla niego zdefiniowany oraz dodatkowo wszystkie porty typu Bridge zdefiniowane dla serwerów, które dany object spawner ma uruchamiać. Dla różnych serwerów numer portu typu Bridge może się powtarzać, gdyż aplikacja żądając uruchomienia serwera, przekazuje informację, jaki serwer ma być uruchomiony.
Porty typu PortBank są wykorzystywane przez sesje pooled workspace serwera.
Sprawdzenie, czy porty nie są zajęte można wykonać za pomocą polecenia netstat.
Po starcie object spawner sprawdza, pod jakimi nazwami serwer jest widoczny w sieci. Informacje te umieszcza w logu. Nazwa ta musi się zgadzać z nazwą serwera podaną dla object spawnera w metadanych (we właściwościach object spawnera na zakładce 'Options').
Jak sprawdzić, któe serwery są startowane przez object spawner?
Serwery, które mają być startowane przez dany object spawner, są przypisane w metadanych. Ich listę można obejrzeć i zmodyfikować wyświetlając właściwości object spawnera na zakładce 'Servers'.
Workspace serwer jest startowany przez object spawner, dlatego każda zmiana w definicji workspace serwera w metadanych wymaga ponownego zaczytania definicji przez object spawner. Można to zrobić restartując object spawner lub podłączając się do niego w konsoli metadanych i wykonując polecenie z pomocniczego menu 'Refresh spawner'.
Jak jest uruchamiany workspace serwer?
Workspace serwer jest uruchamiany przez object spawner na życzenie użytkownika. Komenda startująca jest zapisana w metadanych, we właściwościach workspace serwera, skąd jest odczytywana przez object spawner przy starcie. Domyślnie jest to uruchomienie skryptu WorkspaceServer.bat/WorkspaceServer.sh z katalogu workspace serwera (<sasconfig>/Levx/SASApp/WorkspaceServer).
Workspace serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawner (zakładka 'Servers').
Na jakim koncie jest uruchamiany workspace serwer?
Do uruchomienia standardowego workspace serwera może być użyte konto, na które użytkownik zalogował się do serwera metadanych lub konto odczytane z metadanych. W przypadku, kiedy podany przy logowaniu identyfikator nie może zostać wykorzystany, a w metadanych nie ma dostępnego odpowiedniego loginu (w domenie autentykacji workspace serwera), niektóre aplikacje mogą zapytać o identyfikator i hasło. Login w metadanych może być zdefiniowany bezpośrednio dla użytkownika lub dla grupy, do której należy.
Istnieje możliwoœć zdefiniowania dla workspace serwera autentykacji w oparciu o mechanizm Integrated Windows Authentication (IWA). W takim przypadku workspace serwer będzie startował na koncie użytkownika aktualnie zalogowanego do Windows.
Dla workspace serwera jest również możliwe zdefiniowanie autentykacji tokenowej. Wtedy wszystkie sesje są uruchamiane na tym samym, wskazanym w metadanych, koncie. Dostęp do tego loginu musi mieć użytkownik, za pomocą którego object spawner łączy się z serwerem metadanych (Object Spawner punkt 6).
Niezależnie od tego, jak zostały podane identyfikator i hasło, musi to być konto, które system operacyjny, na którym działa workspace serwer, może zautentykować.
Jakie uprawnienia musi mieć użytkownik, na którym działa workspace serwer?
Użytkownik, na którego koncie będzie startował workspace serwer, musi mieć uprawnienia do odczytu katalogu <sasconfig>/Levx/SASApp i uruchamiania skryptów sas.sh|bat oraz appservercontext_env.sh|bat z tego katalogu, a także do katalogu <sasconfig>/Levx/SASApp/WorkspaceServer i do uruchamiania skryptów WorkspaceServer.sh|bat i WorkspaceServer_usermods.sh|bat. Musi także mieć uprawnienia potrzebne do uruchomienia procesu sas (Serwer Metadanych punkt 6).
Jeżeli workspace serwer został skonfigurowany tak, że będzie tworzył log, użytkownik, na którego koncie jest uruchamiany workspace serwer musi mieć uprawnienia do zapisu w katalogu, w którym będzie tworzony log workspace serwera (Workspace Serwer punkt 4).
Windows
Użytkownik, na którym będzie startowany proces, musi mieć uprawnienie 'Logowanie w trybie wsadowym' (Log on as a batch job). Nie jest ono potrzebne w przypadku, gdy będzie wykorzystywany mechanizm IWA.
Z jakich plików konfiguracyjnych korzysta workspace serwer?
Workspace serwer korzysta z następujących plików konfiguracyjnych zdefiniowanych w środowisku:
- w katalogu <sasconfig>\Levx\SASApp\WorkspaceServer: sasv9.cfg, sasv9_usermods.cfg, autoexec.sas oraz autoexec_usermods.sas
- w katalogu <sasconfig>\Levx\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas oraz appserver_autoexec_usermods.sas.
- <sasconfig>\Levx\metadataConfig.xml, zawierającym informacje, jak połaczyć się z serwerem metadanych
Dodatkowo wykorzystywane są wszystkie standardowe pliki konfiguracyjne używane przy starcie sesji SAS (Serwer Metadanych punkt 6).
Do skonfigurowania logowania jest wykorzystywany plik \Levx\SASApp\WorkspaceServer\logconfig.xml.
Gdzie znajdują się logi workspace serwera?
Standardowo workspace serwer nie tworzy logów. Jeżeli zmienione zostały ustawienia domyślne, wówczas lokalizacja logów jest zapisana w pliku <sasconfig>\Levx\SASApp\WorkspaceServer\logconfig.xml. Logi workspace serwera powinny być zdefiniowane w taki sposób, żeby każdy proces tworzył swój plik z logiem. Każdy użytkownik, na którego startuje workspace serwer musi mieć dostęp do zapisu do katalogu, w którym będą tworzone logi.
Jak wykonywana jest autentykacja użytkownika, na którego koncie ma działać workspace serwer?
Workspace serwer jest uruchamiany przez object spawner, który musi wiedzieć, na jakim koncie proces ma być wystartowany. Informacje te dostaje od aplikacji albo odczytuje z metadanych. Przed wystartowaniem procesu musi nastąpić autentykacja użytkownika. Jest ona wykonywana zawsze w oparciu o system operacyjny. W przypadku Windows najczęściej system operacyjny prześle identyfikator i hasło do AD, gdyż na ogół zdefiniowana jest autentykacja domenowa. W przypadku UNIXa, jeżeli autentykacja ma się odbywać w oparciu o AD/LDAP, niezbędne jest skonfigurowanie mechanizmu PAM.
Stored Process serwer jest startowany przez object spawner, dlatego każda zmiana w definicji serwera w metadanych wymaga ponownego zaczytania definicji przez object spawner. Można to zrobić restartując object spawner lub podłączając się do niego w konsoli metadanych i wykonując polecenie z pomocniczego menu 'Refresh spawner'.
Jak jest uruchamiany stored proces serwer?
Stored process serwer jest uruchamiany przez object spawner. Komenda startująca jest zapisana w metadanych, we właściwościach stored process serwera, skąd jest odczytywana przez object spawner przy starcie. Domyślnie jest to uruchomienie skryptu StoredProcessServer.bat/StoredProcessServer.sh z katalogu stored process serwera (<sasconfig>/Levx/SASApp/StoredProcessServer).
Stored process serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawner (zakładka 'Servers').
Na jakim koncie jest uruchamiany stored process serwer?
Konto, na którym działa stored process serwer jest zapisane w metadanych we właściwościach stored process serwera. Jest ono odczytywane przez object spawner przy starcie. Jeżeli stored process serwer działa na platformie Windows i do uruchamiania serwera jest używany użytkownik lokalny, jego identyfikator w metadanych musi być poprzedzony nazwą maszyny.
Dostęp do wykorzystywanego loginu musi mieć użytkownik, za pomocą którego object spawner łączy się z serwerem metadanych (domyślnie SAS Trusted User). Domyślnie login ten jest zdefiniowany dla grupy SAS General Servers, do której należy SAS Trusted User.
Użytkownik, na którego koncie działa stored proces serwer, jest autentykowany przez system operacyjny.
Jakie uprawnienia musi mieć uzytkownik, na którego koncie jest uruchamiany stored process serwer?
Użytkownik, na którym jest uruchamiany stored process serwer musi mieć uprawnienia do odczytu do katalogu <sasconfig>\Levx\SASApp i <sasconfig>\Levx\SASApp\StoredProcessServer. Musi mieć prawo uruchamiać skrypty z katalogu <sasconfig>\Levx\SASApp\StoredProcessServer: StoredProcessServer.sh|bat oraz StoredProcessServer_usermods.sh|bat, a także skryptów <sasconfig>\Levx\SASApp\sas.sh|bat i <sasconfig>/Levx/SASApp/appservercontext_env.sh|bat. Musi mieć wszystkie uprawnienia, które są potrzebne, żeby uruchomić proces sas (Serwer metadanych punkt 6).
Biblioteka SASUSER dla stored proces serwera jest zdefiniowana w configu serwera jako tylko do odczytu i wskazuje na <sasconfig>\Levx\SASApp\StoredProcessServer\sasuser.
Dodatkowo użytkownik musi mieć uprawnienia do katalogu, w którym zapisywany jest log (punkt 5) oraz do katalogów, w których przechowywane są kody procesów gotowych.
Windows
Użytkownik musi mieć uprawnienie 'Logowanie w trybie wsadowym' (Log on as a Batch job).
Jakie pliki konfiguracyjne wykorzystuje stored process serwer?
Stored process serwer wykorzystuje następujące pliki konfiguracyjne z katalogów środowiska:
- Z katalogu <sasconfig>\Levx\SASApp\StoredProcessServer: sasv9.cfg, sasvg_usermods.cfg, autoexec.sas oraz autoexec_usermods.sas
- Z katalogu <sasconfig>\Levx\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas.
- <sasconfig>\Levx\metadataConfig.xml, zawierającym informacje, jak połaczyć się z serwerem metadanych
Dodatkowo korzysta z wszystkich plików konfiguracyjnych potrzebnych do uruchomienia procesu sas (Serwer metadanych punkt 6).
Do skonfigurowania logowania jest wykorzystywany plik <sasconfig>\Levx\SASApp\StoredProcessServer\logconfig.xml.
Gdzie znajdują się logi stored process serwera?
Ścieżka do katalogu z logami jest zdefiniowana w pliku konfiguracyjnym <sasconfig>\Levx\SASApp\StoredProcessServer\logconfig.xml. Domyślnie logi są tworzone w katalogu <sasconfig>\Levx\Logs lub <sasconfig>\Levx\SASApp\StoredProcessServer\logs.
Na jakich portach działa stored process serwer?
Porty, na których działa stored process serwer, są zdefiniowane w metadanych. Są to porty typu MultiBridge. Zajętość portów można sprawdzić komendą netstat.
Jak jest uruchamiany pooled workspace serwer?
Pooled workspace serwer jest uruchamiany przez object spawner. Komenda startująca jest zapisana w metadanych, we właściwościach pooled workspace serwera, skąd jest odczytywana przez object spawner przy starcie. Domyślnie jest to uruchomienie skryptu PooledWorkspaceServer.bat/PooledWorkspaceServer.sh z katalogu stored process serwera (<sasconfig>/Levx/SASApp/PooledWorkspaceServer).
Pooled workspace serwer jest przypisany do object spawnera w metadanych, we właściwościach object spawnera (zakładka 'Servers').
Na jakim koncie jest uruchamiany pooled workspace serwer?
Konto, na którym działa pooled workspace serwer, jest zapisane w metadanych we właściwościach pooled workspace serwera. Jest ono odczytywane przez object spawner przy starcie. Jeżeli pooled workspace serwer działa na platformie Windows i do uruchamiania serwera jest używany użytkownik lokalny, jego identyfikator w metadanych musi być poprzedzony nazwą maszyny.
Dostęp do wykorzystywanego loginu musi mieć użytkownik, za pomocą którego object spawner łączy się z serwerem metadanych (domyślnie SAS Trusted User). Domyślnie login ten jest zdefiniowany dla grupy SAS General Servers, do której należy SAS Trusted User.
Użytkownik wykorzystywany do uruchomienia pooled workspace serwera jest autentykowany przez system operacyjny.
Jakie uprawnienia musi mieć użytkownik, na którego koncie jest uruchamiany pooled workspace serwer?
Użytkownik, na którym jest uruchamiany pooled workspace serwer musi mieć uprawnienia do odczytu do katalogu <sasconfig>\Levx\SASApp> oraz <sasconfig>\Levx\SASApp\PooledWorkspaceServer. Musi mieć prawo uruchamiać skrypty z katalogu <sasconfig>\Levx\SASApp\PooledWorkspaceServer: PooledWorkspaceServer.sh|bat i PooledWorkspaceServer_usermods.sh|bat, oraz skrypty <sasconfig>/Levx/SASApp/sas.sh|bat i <sasconfig>/Levx/SASApp/appservercontext_env.sh|bat. Musi mieć wszystkie uprawnienia, które są potrzebne, żeby uruchomić proces sas (Serwer metadanych punkt 6).
Dodatkowo musi mieć uprawnienia do katalogu, w którym zapisywany jest log (punkt 5).
Biblioteka SASUSER dla pooled workspace serwera jest zdefiniowana w configu serwera jako tylko do odczytu i wskazuje na <sasconfig>\Levx\SASApp\PooledWorkspaceServer\sasuser.
Windows
Użytkownik musi mieć uprawnienie 'Logowanie w trybie wsadowym' (Log on as a Batch job).
Jakie pliki konfiguracyjne wykorzystuje pooled workspace serwer?
Pooled workspace serwer wykorzystuje następujące pliki konfiguracyjne z katalogów środowiska:
- Z katalogu <sasconfig>\Levx\SASApp\PooledWorkspaceServer: sasv9.cfg, sasvg_usermods.cfg, autoexec.sas i autoexec_usermods.sas
- Z katalogu <sasconfig>\Levx\SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas.
- <sasconfig>\Levx\metadataConfig.xml, zawierającym informacje, jak połaczyć się z serwerem metadanych
Dodatkowo korzysta z wszystkich plików konfiguracyjnych potrzebnych do uruchomienia procesu sas (Serwer metadanych punkt 6).
Do skonfigurowania logowania jest wykorzystywany plik <sasconfig>\Levx\SASApp\PooledWorkspaceServer\logconfig.xml.
Gdzie znajdują się logi pooled workspace serwera?
Ścieżka do katalogu z logami jest zdefiniowana w pliku konfiguracyjnym <sasconfig>\Levx\SASApp\PooledWorkspaceServer\logconfig.xml. Domyślnie logi są tworzone w katalogu <sasconfig>\Levx\Logs lub <sasconfig>\Levx\SASApp\PooledeWorkspaceServer\logs.
Na jakich portach działa pooled workspace serwer?
Porty, na których działa pooled workspace serwer, są to porty typu PortBank zdefiniowane w metadanych dla object spawnera. Porty te są wykorzystywane tylko w czasie połączenia klienta z wybranym procesem pooled workspace serwera. Po rozłączeniu się klienta (wykonaniu kodu), proces dalej działa, a wykorzystany port jest zwracany do puli portów object spawnera. Przy połączeniu kolejnego klienta object spawner przydzieli procesowi wolny port z puli dostępnych portów.
Jak uruchomić OLAP serwer?
Sugerowaną metodą startowania serwera jest wykorzystanie skryptu /Levx/sas.servers, który służy do uruchamiania i zatrzymywania wszystkich procesów środowiska działających na danej maszynie:
./sas.servers start
Dostępny jest również skrypt służący tylko do startowania i zatrzymywania serwera OLAP. Znajduje się on w katalogu serwera: <sasconfig>/Levx/SASApp/OLAPServer:
./OLAPServer start
Windows
Najczęściej OLAP serwer jest zdefiniowany jako usługa, wystarczy więc uruchomić ją. Skrót do wystartowania serwera może być również umieszczony w Start -> Programy -> SAS. Dostępny jest również skrypt w katalogu OLAP serwera: <sasconfig>\Levx\SASApp\OLAPServer:
OLAPServer.bat start
Obie platformy
Po starcie OLAP serwer łączy się z serwerem metadanych, dlatego musi być uruchomiony po starcie serwera metadanych.
Jak sprawdzić, czy OLAP serwer działa?
UNIX
Status serwera OLAP można sprawdzić za pomocą skryptu sas.servers, znajdującego się w katalogu <sasconfig>/Levx:
sas.server status
Inną metodą jest wykorzystanie skryptu znajdującego się w katalogu serwera (<sasconfig>/Levx/SASApp/OLAPServer):
OLAPServer.sh status
Windows
Jeżeli OLAP serwer działa jako usługa, wystarczy sprawdzić status usługi. Można również wykorzystać skrypt znajdujący się w katalogu serwera (<sasconfig>\Levx\SASApp\OLAPServer):
OLAPServer.bat status
Jakie uprawnienia musi mieć użytkownik, na koncie którego działa serwer OLAP?
Użytkownik, na którym startuje serwer OLAP musi mieć uprawnienia do odczytu katalogu serwera OLAP (<sasconfig>/Levx/SASApp/OLAPServer), do uruchamiania skryptu startującego serwer OLAP (OLAPServer.sh z katalogu serwera) oraz skryptu <sasconfig>/Levx/SASApp/appservercontext_env.sh|bat. Musi mieć uprawnienia do zapisu do katalogu, w którym będzie tworzony log serwera (punkt 6), jak również uprawnienia niezbędne do uruchomienia procesu SAS (Serwer Metadanych punkt 6). Ponieważ w systemie operacyjnym serwer OLAP to jeden proces, działający w imieniu konkretnego użytkownika, to ten użytkownik musi mieć uprawnienia do odczytu do wszystkich katalogów, w których są przechowywane fizyczne pliki kostek.
Jeżeli w SASie została zdefiniowana opcja UTILLOC lub SPDEUTILLOC, wówczas użytkownik musi mieć dostęp do zapisu do ścieżek podanych w ramach tych opcji.
Serwer OLAP nie powinien być startowany na koncie Root.
Biblioteka SASUSER dla OLAP serwera jest zdefiniowana w configu serwera jako tylko do odczytu i wskazuje na <sasconfig>\Levx\SASApp\OLAPServer\sasuser.
OLAP serwer po starcie, a także w ciągu całej swojej pracy kontaktuje się z serwerem metadanych. Połączenie to odbywa się za pomocą specjalnego użytkownika, który musi być zdefiniowany jako "trusted user" (domyślnie jest to SAS Trusted User). Wszystkie parametry potrzebne do połączenia z serwerem metadanych (w tym użytkownik) są zapisane w pliku <sasconfig>/Levx/sasv9_meta.cfg.
Jakie pliki konfiguracyjne wykorzystuje serwer OLAP?
OLAP serwer wykorzystuje następujące pliki konfiguracyjne:
- z katalogu <sasconfig>/Levx/SASApp/OLAPServer: sasv9.cfg, sasv9_usermods.cfg, , autoexec.sas, autoexec_usermods.sas, logconfig.xml
- z katalogu <sasconfig>/Levx/SASApp: sasv9.cfg, sasv9_usermods.cfg, appserver_autoexec.sas, appserver_autoexec_usermods.sas
- <sasconfig>/Levx/metadataConfig.xml i <sasconfig>/Levx/sasv9_meta.cfg - tutaj są podane parametry połączeniowe do serwera metadanych.
Dodatkowo serwer OLAP wykorzystuje wszystkie pliki konfiguracyjne używane przy uruchomieniu procesu SAS (Serwer Metadanych punkt 6).
Na jakim porcie działa serwer OLAP?
Numer portu, na którym działa OLAP serwer, jest zapisany w metadanych w obiekcie Connection zdefiniowanym dla serwera. Zajętość portu można sprawdzić komendą NETSTAT.
Gdzie znajduje się log serwera OLAP?
Mechanizm logowania dla serwera OLAP jest zdefiniowany w pliku konfiguracyjnym serwera logconfig.xml. Domyślnie log jest zapisywany w katalogu <sasconfig>\Levx\SASApp\OLAPServer\logs lub <sasconfig>\Levx\Logs.
Dodatkowo na UNIXie jest tworzony log SASApp_OLAPServer_console.log, który jest zdefiniowany w skrypcie startującym OLAP serwer (<sasconfig>/Levx/SASApp/OLAPServer/OLAPServer.sh).
Jakie uprawnienia musi mieć użytkownik, żeby wyświetlić dane z kostki?
Użytkownik, który chce odczytać dane z kostki musi mieć zdefiniowane dla kostki uprawnienia Read i ReadMetadata. Mogą być one nałożone bezpośrednio na kostkę lub na folder, w którym znajduje się kostka (bezpośrednio lub pośrednio), ew. w domyślnym schemacie zdefiniowanym dla repozytorium.
W systemie operacyjnym dostęp do fizycznych plików musi mieć użytkownik, na którym działa serwer OLAP.
Jak autentykuje serwer OLAP?
Jeżeli użytkownik łączy się najpierw z serwerem metadanych, a potem z serwerem OLAP, to serwer OLAP wykorzystuje autentykacje tokenową, tzn. serwer metadanych generuje specjalny token, który jest przez aplikację kliencką przekazywany do serwera OLAP, który z kolei zwraca token do weryfikacji do serwera metadanych.
W niektórych przypadkach użytkownicy mogą łączyć się z serwerem OLAP bezpośrednio. Wówczas serwer OLAP jest odpowiedzialny za dokonanie autentykacji. Domyślnie korzysta z autentykacji poprzez system operacyjny, ale może mieć zdefiniowane alternatywne sposoby autentykacji tak, jak serwer metadanych (Serwer Metadanych punkt 11).