Kakšen sever za sql in domeno z cca. 100 uporabnik

igi · 21. jan 2008

Pozdravljeni!

Za podjetje rabim nov server, ker počasi staremu zmanjkuje hitrosti

Na starem je sedaj zložen sbs server 2003 in poganja sql. Domene ni! Ker pa se je podjetje v enem letu razširilo, kar se uporabnikov tiče za 400% bo potrebna menjava!

Sedaj pa ne vem kako se lotiti zadeve. Rabil bil 110% zanesljivost

, rabim SQL, pa domena bi bila tudi dobrodošla!

Pa ne vem ali je bolje kupiti dva strežnika in na enem vrteti samo SQL na drugem pa domeno, ali stlačiti vse na enega (mogoče kekšen virtual pc), ali?
Kako rešiti pogoj zanesljivosti? Obstaja kakšna varianta z replikacijo baze? Ali pa bi bilo mogoče smiselno razmišljati o zunanjem diskovnem polju?

v glavnem kakršen koli nasvet je dobrodošel!

Hvala

bles · 21. jan 2008

Vsak te bo vprašal, kaj poganja ta SQL? Ker pol se lahko dalje pogovarjamo.

bles

tis · 21. jan 2008

Res bi bilo dobro, da napišeš kaj več:
- Glede na to, da govoriš SBS 2003 in o SQL predvidevam, da govoriš o Windows Small Business Server 2003 in MS SQL Serverju, ki je del tega. Lahko se pa motim.
- Povedal si, da se je število uporabnikov v enem letu zelo razširilo - nič pa nisi omenil načrte za naprej. To je zelo pomembno.
- Dodatno je smiselno opredeliti za kakšne operacije gre

Drugače pa par smernic:
- Veliko bolj se ti splača ločiti spletni in podatkovni strežnik kot pa oboje tlačiti na isto mašino (ti to imenuješ strežnik za SQL in strežnik za domeno
- Glede na to, da ciljaš na 110% zanesljivost ti moram predlagati, da malce spustiš standarde. Če pa še vedno vstrajaš na tem pa moraš poskrbeti za ustrezen RAID, standby strežnik (replikacija) z avtomatskim failover ipd... A potem moraš zopet preveriti kaj vse ti omogoča baza, katero uporabljate.

Zato predlagam, da v podjetju resno premislite kakšne so vaše realne zahteve (koliko časa je lahko strežnik dol) in glede na tvoje zahteve in število uporabnikov morda za vzdrževanje sistema podpišete pogodbo s kakšno firmo, ki bo garantirala zelo dober odzivni čas, začasno zamenjavo strežnikov (v primeru napake) ...

igi · 21. jan 2008

- število uporabnikov se bo načeloma povečavalo cca. 10% letno
- SQL poganja kompleten poslovni program TIC (comtron - pač tako so se v podjetju odločili pred dvema letoma )
- trenutno zadeva deluje na enem xeon 3.2 serverju z 3gb rama, in je na trenutke počasna (sploh ko se poganjajo kakšna poročila, obdelave)
- zanesljivost: JA tistih 110% je bilo napisano bolj v hecu kot zares, bi pa bilo seveda fino, da je izpada čim manj. Maloprodaja sicer lahko deluje nekaj časa na offline, veleprodaja pa je bolj občutljiva... Tukaj mi bolj malo pomaga dobra pogodba, ker bomo v vsakem primeru izgubili en dan!

bles · 21. jan 2008

Vprašanj Comtronovce kakšen strežnik potrebuješ. Pa da vidiš kao stavri stojijo.

bles

Nobody · 21. jan 2008

Comtron in TIC ja ... se kr spomnim kak je to zgledalo, ko sem reko, da mi naj nekaj pogledajo za zalogo ... trajalo in trajalo

tis · 21. jan 2008

Moj predlog (oz. dodatne smernice):
Podatkovno bazo namestite na nov podatkovni strežnik (predlagam brand strežnike)
- Morda nekaj takega (HP ML370), seveda z ustrezno konfiguracijo diskovnih polj
- Diskov kolikor potrebujete za RAID, če uporabljate RAID5, potem bolje več manjših kot le tri velike
- RAM 4GB
- 1 Procesor, price/performance ugoden; kasneje lahko po potrebi nadgradite

Obstoječi strežnik uporabite za middle-tier in spletni strežnik:
- S tem boste razbremenili podatkovni strežnik - saj ne bo obremenjen s procesiranjem poslovnih pravil
- obstoječ strežnik je za zadano nalogo več kot zadosten
- na njem lahko gostite tudi standby sistem (w/o)

Kakšno imate sedaj diskovno konfiguracijo?

KrNeki99 · 22. jan 2008

he he, tud jest mislim da je (ne)hitrost tukaj bolj povezana s programsko kot pa s strojno opremo

lp

igi · 22. jan 2008

Citat:
Uporabnik KrNeki99 pravi:
he he, tud jest mislim da je (ne)hitrost tukaj bolj povezana s programsko kot pa s strojno opremo

lp

hja... sem tudi jst podobnega mnenja, samo "mojstri" pravijo, da je server v qurcu

Pa kaj bi jim oporekali, sej so vendar strokovnjaki.....

igi · 22. jan 2008

Citat:
Uporabnik tis pravi:
Moj predlog (oz. dodatne smernice):
Podatkovno bazo namestite na nov podatkovni strežnik (predlagam brand strežnike)
- Morda nekaj takega (HP ML370), seveda z ustrezno konfiguracijo diskovnih polj
- Diskov kolikor potrebujete za RAID, če uporabljate RAID5, potem bolje več manjših kot le tri velike
- RAM 4GB
- 1 Procesor, price/performance ugoden; kasneje lahko po potrebi nadgradite

Obstoječi strežnik uporabite za middle-tier in spletni strežnik:
- S tem boste razbremenili podatkovni strežnik - saj ne bo obremenjen s procesiranjem poslovnih pravil
- obstoječ strežnik je za zadano nalogo več kot zadosten
- na njem lahko gostite tudi standby sistem (w/o)

Kakšno imate sedaj diskovno konfiguracijo?

sedaj imamo 3 diske po 72gb v raid 5...

Comtronovci so si zamislili nekaj takega : HP ML350G5, 2x Quad-Core Intel Xeon E5310 Processor, 3 x HP RAM 4GB FBD PC2-5300, 4x HP disk 146GB 10K SAS 2.5 HP HDD...
Po specifikacijah bi zadeva MORALA izboljšati performanse

Ateis · 22. jan 2008

a boš mel gor sbs 2003?

lp

tis · 22. jan 2008

Citat:
Uporabnik igi pravi:
sedaj imamo 3 diske po 72gb v raid 5...

Comtronovci so si zamislili nekaj takega : HP ML350G5, 2x Quad-Core Intel Xeon E5310 Processor, 3 x HP RAM 4GB FBD PC2-5300, 4x HP disk 146GB 10K SAS 2.5 HP HDD...
Po specifikacijah bi zadeva MORALA izboljšati performanse

Zanimivo... pa ti niso predlagali, da ločiš podatkovni nivo od poslovnega nivoja?
Če boš imel še naprej oboje na istem strežniku potem je njihova kombinacija seveda ustreznejša in bo sigurno izboljšala performance (a je tudi dražja).

igi · 22. jan 2008

Citat:
Uporabnik Ateis pravi:
a boš mel gor sbs 2003?

lp

na novem mi bi bil SBS premalo zato bo kar navaden + licenca za sql 2005...

igi · 22. jan 2008

Citat:
Uporabnik tis pravi:

Citat:
Uporabnik igi pravi:
sedaj imamo 3 diske po 72gb v raid 5...

Comtronovci so si zamislili nekaj takega : HP ML350G5, 2x Quad-Core Intel Xeon E5310 Processor, 3 x HP RAM 4GB FBD PC2-5300, 4x HP disk 146GB 10K SAS 2.5 HP HDD...
Po specifikacijah bi zadeva MORALA izboljšati performanse

Klikni za razširitev

Zanimivo... pa ti niso predlagali, da ločiš podatkovni nivo od poslovnega nivoja?
Če boš imel še naprej oboje na istem strežniku potem je njihova kombinacija seveda ustreznejša in bo sigurno izboljšala performance (a je tudi dražja).

Tegale ne razumem: "Zanimivo... pa ti niso predlagali, da ločiš podatkovni nivo od poslovnega nivoja? "
Poslovni je po moje SQL baza in podatkovni bi naj bil recimo podatki uporabnikov v domeni?

trenutno mašine niso v domeni!
na starem serverju se uporablja le SQL... Prav tako bi na novega naložili le to!

Bi pa rad počasi računalnike spravil v domeno, zato razmišlam o drugih kombinacijah!

Hvala

tis · 22. jan 2008

Na njihovi spletni strani opisujejo tehnološko rešitev TIC-a za katerega si omenil, da je namenjen strežnik.

Po njihovih podatkih (sam TIC ne poznam) tehnološka rešitev TIC temelji na večnivojski arhitekturi in sicer:
- lahi odjemalec
- aplikacijski strežnik (poslovna pravila)
- podatkovni strežnik (podatkovna baza)

Pri tovrstni arhitekturi je prva logična rešitev, da ločiš aplikacijski nivo od podatkovnega nivoja, saj pri velikem številu uporabnikov oba obremenjujeta tako RAM, CPU kot tudi I/O **. Vzpostavitev dedicated strežnikov za posamezen nivo je pri večanju števila uporabnikov prva rešitev.

Druga rešitev je seveda nabaviti full zmogljiv strežnik in uporabnik bo zadovoljen... čeprav bo ponavadi za več denarja prišel do slabše rešitve (tudi glede odzivnosti). Seveda je vse odvisno tudi od arhitekture sistema a kakor so oni na svoji spletni strni opisali...

** tu moram seveda dodati (za tiste, ki si ne predstavljajo): baza ima svoje zahteve, in izvaja lastne operacije; poslovni nivo (aplikacija) ima svoje zahteve in izvaja lastne operacije... tako ponavadi pride do ozkega grla predvsem pri I/O, na Windows sistemih pa verjetno tudi CPU-ja ne zna najbolje izkoristiti (vsaj včasih je bilo tako).

igi · 22. jan 2008

Citat:
Uporabnik tis pravi:
Na njihovi spletni strani opisujejo tehnološko rešitev TIC-a za katerega si omenil, da je namenjen strežnik.

Po njihovih podatkih (sam TIC ne poznam) tehnološka rešitev TIC temelji na večnivojski arhitekturi in sicer:
- lahi odjemalec
- aplikacijski strežnik (poslovna pravila)
- podatkovni strežnik (podatkovna baza)

Pri tovrstni arhitekturi je prva logična rešitev, da ločiš aplikacijski nivo od podatkovnega nivoja, saj pri velikem številu uporabnikov oba obremenjujeta tako RAM, CPU kot tudi I/O **. Vzpostavitev dedicated strežnikov za posamezen nivo je pri večanju števila uporabnikov prva rešitev.

Druga rešitev je seveda nabaviti full zmogljiv strežnik in uporabnik bo zadovoljen... čeprav bo ponavadi za več denarja prišel do slabše rešitve (tudi glede odzivnosti). Seveda je vse odvisno tudi od arhitekture sistema a kakor so oni na svoji spletni strni opisali...

** tu moram seveda dodati (za tiste, ki si ne predstavljajo): baza ima svoje zahteve, in izvaja lastne operacije; poslovni nivo (aplikacija) ima svoje zahteve in izvaja lastne operacije... tako ponavadi pride do ozkega grla predvsem pri I/O, na Windows sistemih pa verjetno tudi CPU-ja ne zna najbolje izkoristiti (vsaj včasih je bilo tako).

ja hvala za obrazložitev!

Verjetno se aplikacijskemu strežniku drugače reče še MTS strežnik (to pa res že imamo), tako da so v bistvu uporabniki že razbiti na 3 dele... ampak hitrost se ni povečala skoraj nič!

Problem je, ko kdo zažene kakšno poročilo (ni trebe da je to nekaj kompleksnega) takrat blagajne ne gredo nikamor več.... Pa so na svojem MTS strežniku...

Res hvala za pomoč in "drugo mnenje", ker njihova ideja je samo "zamenjat treba server, ker je prešvohno....." Verjetno bo naslednja stvar optično omrežje

tis · 22. jan 2008

Citat:
Uporabnik igi pravi:
Verjetno se aplikacijskemu strežniku drugače reče še MTS strežnik (to pa res že imamo), tako da so v bistvu uporabniki že razbiti na 3 dele... ampak hitrost se ni povečala skoraj nič!

Problem je, ko kdo zažene kakšno poročilo (ni trebe da je to nekaj kompleksnega) takrat blagajne ne gredo nikamor več.... Pa so na svojem MTS strežniku...

Res hvala za pomoč in "drugo mnenje", ker njihova ideja je samo "zamenjat treba server, ker je prešvohno....." Verjetno bo naslednja stvar optično omrežje

Pa je kakšen DB admin pregledal bazo, indekse ipd..., da bi ugotovil kaj ustvarja ta bottleneck? Zaganjanje enostavnih poročil v nobenem primeru ne sme zaustaviti celotnega sistema. Sam imam sicer izkušnje na Oracle sistemih a RDBMS je RDBMS.

ups... še tole: optika med strežniki ne bo rešila težav, ki jih opisuješ (počasna enostavna poročila). To je izključna težava zahtevkov na podatkovnem strežniku.

Pepe · 22. jan 2008

SQLServer se trudi, da posamezno akcijo zaključi čim hitreje. To je logično, ker vsaka akcija zahteva določena zaklepanja in ostale akcije bi lahko vseeno čakale, ker zapisi ni na voljo. Zelo poenostavljena razlaga: ko uporabnik požene poročilo nad aktivno bazo in SELECT pride na vrsto, bo SQL server naredil vse, da to izvrši, ostali pa bolj ali manj "stojijo". Na SQL serverju ni možno določiti prioritete izvajanja znotraj iste podatkovne baze, npr. "poročila pa lahko trajajo 20% dalj, samo da so blagajne hitre". Sam običajno povpraševanja za poročila naredim tako, da tečejo samo na enem procesorju, tudi če jih strežnik ima več. Na štiri procesorskem strežniku potem to pomeni, da so bolj ali manj štirje uporabniki paralelni. Seveda pa lahko taka rešitev pomeni, da zaradi zaklepanja vse dela še počasneje. Odvisno od vsebine problema. Lahko se odločimo in beremo brez zaklepanja, ampak v praksi to pomeni, da rezultat v določenih situacijah ni konsistenten. Včasih si to lahko privoščimo, običajno pa ne.
Verjamem, da je v takem sistemu strežnik baze podatkov ozko grlo in dober HW pomaga. Razen tega pomaga tudi kakšna optimizacija tipično glede na način dela stranke in razporeditev podatkov. Po mojem te tako hudo niso nasrali, ko so predlagali, da nabavi nov HW.

Roberto · 22. jan 2008

Evo, da se vmešam:
-če ne misliš uporabljati 64 bitne verzije Win2003 in SQL2005 potem je đabe toliko RAMa (če sem prav videl 3 moduli po 4 GB) saj je omejitev 32-bitne platforme 4 GB, dotični HW pa jo prikaže samo 3,5 GB na 32bitni platformi.-
-kreiraj 3 diskovna polja; sistem in transakcijske loge na RAID1, bazo na RAID5
-si razmišljal o gruči (cluster) in SANu?
-za domenca potrebuješ potem nov server (2), ki pa se bosta zadovoljila z 1 GB RAM, 72GB diskom v RAID1 in mrežno karto... Kakšen HP DL360 bo čistov v redu...
Če si prerastel SBS okolje (kar očitno si) boš moral ločiti servise po strežnikih. Izogibaj se home-made variant...
Optično omrežje... hrbtenico (strežnike) na DOBER GBit switch in uredi teaming (link agregation), tako da bodo serverji povezani na hrbtenico vsaj z 2 GB linkom.
Uporabnike postaviš na svoj switch (100 MBit za uporabnike 1GBit uplink) in performance se ti bodo izboljšale. Ne pozabi pa še na tweak na DL360/380 G5 mrežni karti, drugače so preformance v eno smer v buli.
Pa izogibal bi se garažnih firm, ki ti niso sposobne nuditi dobrega supporta in postaviti zadevo "by the book".

tis · 22. jan 2008

Citat:
Uporabnik Pepe pravi:
SQLServer se trudi, da posamezno akcijo zaključi čim hitreje. To je logično, ker vsaka akcija zahteva določena zaklepanja in ostale akcije bi lahko vseeno čakale, ker zapisi ni na voljo. Zelo poenostavljena razlaga: ko uporabnik požene poročilo nad aktivno bazo in SELECT pride na vrsto, bo SQL server naredil vse, da to izvrši, ostali pa bolj ali manj "stojijo". Na SQL serverju ni možno določiti prioritete izvajanja znotraj iste podatkovne baze, npr. "poročila pa lahko trajajo 20% dalj, samo da so blagajne hitre". Sam običajno povpraševanja za poročila naredim tako, da tečejo samo na enem procesorju, tudi če jih strežnik ima več. Na štiri procesorskem strežniku potem to pomeni, da so bolj ali manj štirje uporabniki paralelni. Seveda pa lahko taka rešitev pomeni, da zaradi zaklepanja vse dela še počasneje. Odvisno od vsebine problema. Lahko se odločimo in beremo brez zaklepanja, ampak v praksi to pomeni, da rezultat v določenih situacijah ni konsistenten. Včasih si to lahko privoščimo, običajno pa ne.

Upam, da se hecaš!
Zakaj med poivedbo za poročilo stojijo vse ostale transakcije? Potem SQL Server sploh ni pravi RDBMS.

Kakšen sever za sql in domeno z cca. 100 uporabnik

Guru

Pripravnik

Fizikalc

Guru

Pripravnik

is perfect.

Fizikalc

Pripravnik

Guru

Guru

Guru

Fizikalc

Guru

Guru

Fizikalc

Guru

Fizikalc

Guru

Majstr

Fizikalc