Wybór serwera dla XL i Optimy

[bartezgo]

Witam,

nadszedł czas na wymianę serwera dla XL i Optimy.

Co mam:
- LAN 1 Gb/s na switch'ach HP
- ERP XL - baza 1 GB, użytkowników 15 nie przez terminal
- Optima - baza 300 MB, użytkowników 3
- obecnie MS SQL Express 2008
- XL i Optima leżą na tej samej maszynie

Pytania:
- czy zwracać uwagę na ilość procesorów?
- jakie macierze, ile dysków?
- MS SQL 2014 Standard - partner ma lepsze ceny nawet gdy kupię serwer i licencje na OS u innego dostawcy?
- pamięć RAM i więcej tym lepiej
- czy partner może zrobić jakąś "optymalizację" bazy?

Budżet - około 20 tyś netto na hardware+software. Mam ofertę od partnera ale wolę doradzić się Was w kwestii dobrania sprzętu.

Dzięki za podpowiedzi.

[glaz]

Witam,
Pytania:
- czy zwracać uwagę na ilość procesorów?

Tak i nie.
Jazda licencyjna zaczyna się wtedy gdy stosujecie lub planujecie zastosować aplikację klasy "Pulpit kontrahenta" czyli udostępniająca dane z bazy operatorom (klientom) spoza określonej puli użytkowników w firmie. W skrócie: wtedy zamiast liczyć CAL per użytkownik musicie zacząć licencje per core/rdzeń. Model per procesor(bez względu na ilość rdzeni) został zarzucony przez MS :-/.

- MS SQL 2014 Standard - partner ma lepsze ceny nawet gdy kupię serwer i licencje na OS u innego dostawcy?

Z tymi "lepszymi cenami" byłbym bardzo ostrożny. Partner i C. może dać lepsze ceny na SQLS dzięki umowie z MS, która pozwala na odpalenie baz związanych bezpośrednio z produktem/grupą produktów do którego jest dodawana. Trzeba baaardzo uważnie przeczytać umowę licencyjną (bo zapisy z wersjami się zmieniają), żeby się nie okazało , że np dodanie bazy zewn. programu serwisowego łamie warunki licencji SQLS w wersji "partnerskiej".

- pamięć RAM i więcej tym lepiej

Zasadniczo tak, choć nie do końca. W dużym uproszczeniu :zadbaj o "schowanie" bieżącej bazy w RAM, oszacuj roczne przyrosty bazy i pomnóż przez przewidywany czas amortyzacji sprzętu (3-5 lat) takie oszacowanie pomnóż przez współczynnik bezpieczeństwa (20%) i masz RAM którego potrzebujesz

Przykład:
1,3 Gb danych = 1,3 Gb RAM + 700 Mb na system i usługi dodatkowe. = 2 Gb RAM
przyrost bazy = 200M+20M / rok = 220M RAM / rok
5 lat założonej eksploatacji => 220M * 5 = + 1,1 Gb RAM będzie potrzebne za 5 lat
Po pięciu latach baza schowa się w 2,4 Gb RAM
Dla nieprzewidzianych przyrostów i nieoczekiwanych sytuacji +20%
1,1 * 1,2 = 1,32 Gb RAM
Czyli spokojnie można założyć zapotrzebowanie na poziomie 1,3 + 1,32 + 0,7 = 3,02 Gb RAM
Zaokrąglenie w górę: 4 Gb RAM

Rzecz jasna bufory SQLS to nie wszystko - przetworzenie danych też potrzebuje swojej przestrzeni więc pod powyższe wartości podstaw wielkość RAM pożeraną z obecnej instalacji.

- czy partner może zrobić jakąś "optymalizację" bazy?

"Jakąś" zawsze. Choćby przez wywołanie dbcc reindex .
Pytanie czego oczekujesz po tej "optymalizacji":

Zmniejszenia czasu odpowiedzi na krytyczne zapytanie specyficznego klienta jakim jest CDN XL czy O! ?
Skrócenie czasu na przetwarzanie dużej puli danych w jakimś raporcie ?
itd itp ...

[scribe]

bardzo ciekawy temat, a co gdy mam bazę wielkości 40GB i roczny przyrost 5GB

obecnie dysponuje 32GB RAM i jest ok - ale czy w takim razie powyższa kalkulacja się do tego nie odnosi?


planuje wymienić serwer - obecnie mam 2 procesorwy sprzęt z 64GB z TB HDD na którym stoi HV (DNS + SERWER TERMINALI + SQL), wszystko na 2008R2

czy dla takiej bazy iść w macierz czy może jeszcze spokojnie zostać na 1T (z drugiej strony myślałem o zamianie zwykłych dysków na SSD ) - sprzęt chciałbym na kolejne 3-4lata

[RomanP]

Ciekawe jak długo dysk SSD wytrzyma na serwerze?
Operacji zapisu jest tu kilkaset razy więcej niż w komputerze normalnego usera.

[glaz]

Ciekawe jak długo dysk SSD wytrzyma na serwerze?
Operacji zapisu jest tu kilkaset razy więcej niż w komputerze normalnego usera.

Desktopowy 2,5" z miesiąc Może.

Jeśli mówimy o SSD dla baz danych to raczej klasy Enterprise (PCI-e) - tam już ten problem jest ładnie obsłużony, np przez pamięć RAM podtrzymywaną bateryjnie i zrzuty na pamięć flash. Inna sprawa, że bez 10k zł nie podchodź

[glaz]

bardzo ciekawy temat, a co gdy mam bazę wielkości 40GB i roczny przyrost 5GB

obecnie dysponuje 32GB RAM i jest ok - ale czy w takim razie powyższa kalkulacja się do tego nie odnosi?

Zacytuję siebie: " W dużym uproszczeniu "

To jest oszacowanie a nie dokładna kalkulacja, chodziło o wyznaczenie rzędu wielkości pamięci operacyjnej wystarczającej do prawidłowej pracy SQLS przy podanym założeniu (RAM nie jest drogi ale po co ładować 128 GB do instalacji która tego nie potrzebuje, tym bardziej że płyty obsługujące takie wolumeny do tanich już nie należą). Autor postu nie dał żadnego materiału do dokładniejszej analizy i na takim poziomie ogólności na jakim było pytanie dostał odpowiedź.

Jeśli chcesz dokładniejszego wyniku to zbadaj wskaźniki swojej instalacji - zobaczysz co i jak buforuje SQLS. dla wskazanych zasobów (bloki tabel trzymane w pamięci, indeksy, obszary przetwarzania transakcji i tabel tymczasowych zaczepionych w pamięci, obszary przeznaczone na przetwarzanie obiektów, bufory itd itp), a nie dla pliku bazy - wtedy będziesz miał kalkulację i będziesz wiedział czemu 32 GB RAM wystarczy (lub nie) dla bazy 150GB.

Jeśli nie chcesz tego liczyć i obserwować, zastosuj oszacowanie - zazwyczaj się sprawdza, zostawiając dużą rezerwę RAM dla niezbadanych obszarów pracy SQLS .

[Swiety_M]

Ciekawe jak długo dysk SSD wytrzyma na serwerze?
Operacji zapisu jest tu kilkaset razy więcej niż w komputerze normalnego usera.

A jak myślisz na jakich dyskach działają macierze hybrydowe? Albo w 100% na SSD?
SSD w serwerze czy macierzy to nie są dyski SSD jak do laptopa .

Popatrz na macierze hybrydowe IBM Storwize, które zostały produktem roku magazynu it professional.

Powiem ci jedno raz spróbujesz macierzy hybrydowej i już nie będzie cie interesowało nic innego

[RomanP]

"Popatrz na macierze hybrydowe IBM Storwize, które zostały produktem roku magazynu it professional."

Tylko nieśmiało spytam, ile to kosztuje?

Trochę czytam o tym, bo myślę u nas o jakiejś zmianie, ale bez szaleństw,
użytkowników aktywnych jest średnio 20.
Co byłoby jakimś kompromisem?

[Swiety_M]

Macierz V3700 SAS
1 IBM Storwize V3700 SFF Dual Control Enclosure 1 13 850.00 zł 13 850.00 zl
2 8GB Cache Memory Upgrade 2 3 300.00 zł 6 600.00 zl
3 200GB 6Gb SAS 2.5in SSD 4 4 915.00 zł 19 660.00 zl
4 300GB 2.5In 15K rpm 6Gb SAS HDD 0 1 350.00 zł
5 600GB 2.5In 10K rpm 6Gb SAS HDD 12 815.00 zł 9 780.00 zl
6 900GB 2.5In 10K rpm 6Gb SAS HDD 0 1 715.00 zł
7 1.2TB 2.5in 10K 6Gb SAS HDD 0 2 245.00 zł
8 6Gb SAS 4 Port Host Interface Card 2 2 205.00 zł 4 410.00 zl
9 3 Year Onsite Repair 24x7 24 Hour Committed Service (CS) 1 4 600.00 zł 4 600.00 zl
10 3m SAS Cable (mSAS HD to mSAS) 2 440.00 zł 880.00 zl

Total 59 780.00 zl

Nie wiem jakie masz potrzeby, ja potrzebowałem czegoś mocniejszego bo mam bazę niecałe 200 GB, aplikacji kupę pracujących na API i ze 60 userów w tym 25 magazynierów pracujących 24h i kompletujących kilkaset zamówien dziennie po kilkaset pozycji + WMS zintegrowany z XL.

To cena cennikowa od tego jeszcze jakiś rabat dostałem. Generalnie mam uruchomioną na macierzy funkcję EasyThier polega to na tym, że mam 16 dysków w tym 4 SSD, na SSD jest oddzielna grupa dyskowa i dane "HOT" do których dostęp jest najczęstszy macierz automatycznie migruje na SSD.

Generalnie też długo myślałem nad SSD, ale jak wyliczyli mi panowie z IBM wydajność przy takiej konfuguracji z EasyThier, bez SSD osiągnąłnym na normalnych dyskach przy dwóch półkach czyli 2 x 24 DYSKI. Więc łatwo porównać 16 dysków do 48 w tym dodatkowa półka

[RomanP]

Ceny nie są takie straszne
Z tym że u mnie baza ma 6GB, userów około 25, 8 godz. dziennie.
Co najmniej 50% tego ruchu robią programy z API, z tym że właśnie wdrażamy
samodzielne rozliczanie pracowników na stanowiskach i spowoduje to niezły
ruch (około 100 osób wykonujących kilkanaście czynności dziennie).
Więc i baza pewnie urośnie.
Poszukam może coś tańszego.