on useampi palvelin missä on käytössä seagaten 2tb levyjä sitten western digital 500gb ja 1tb levyjä. kahdessa palvelimessa on järjestelmä levynä wd 1tb levy ja nämä ovat dcitä joten write caching on pois päältä noille levyille.
yhdessä palvelimessa havaitaan huono kirjoitusnopeus vain n. 20mbyte/sek. toisessa kirjoitus nopeus järjestelmä levylle on n. 45mbyte/sek. muille kuin järjestelmä levyille kirjoitusnopeudet ovat reilusti toista sataa mbyte/sek joten ei ongelmaa. lukunopeuedt kunnossa.
jos tekee linux pohjaisen acronis boot levyn ja yrittää ajaa varmuuskopion tuolle jossa kirjoitusnopeus vain 20mbyte/sek niin aluksi menee noin 70mbyte/sek ja palvelin käyttää kaiken ram muistin ja muuttuu todella hitaaksi, silloin varmuuskopiointi myös jäätyy. kun vetää varmuuskopio koneesta verkkokaapelin irti niin palvelin jauhaa vielä n. 10-15min kiintolevyn valo koko ajan palaen muistia tyhjäksi kunnes tilanne normalisoituu.
jos taas kopioi windows työasemasta vaikka 20 gigan tiedostoa niin vastaavaa ei tapahdu mutta nopeus on huono.
ja tässä ongelma palvelimessa on vielä exchange jonka databaset on tuolla järjestelmä levyllä. server 2008 r2. missä vika.
yhdessä palvelimessa havaitaan huono kirjoitusnopeus vain n. 20mbyte/sek. toisessa kirjoitus nopeus järjestelmä levylle on n. 45mbyte/sek. muille kuin järjestelmä levyille kirjoitusnopeudet ovat reilusti toista sataa mbyte/sek joten ei ongelmaa. lukunopeuedt kunnossa.
jos tekee linux pohjaisen acronis boot levyn ja yrittää ajaa varmuuskopion tuolle jossa kirjoitusnopeus vain 20mbyte/sek niin aluksi menee noin 70mbyte/sek ja palvelin käyttää kaiken ram muistin ja muuttuu todella hitaaksi, silloin varmuuskopiointi myös jäätyy. kun vetää varmuuskopio koneesta verkkokaapelin irti niin palvelin jauhaa vielä n. 10-15min kiintolevyn valo koko ajan palaen muistia tyhjäksi kunnes tilanne normalisoituu.
jos taas kopioi windows työasemasta vaikka 20 gigan tiedostoa niin vastaavaa ei tapahdu mutta nopeus on huono.
ja tässä ongelma palvelimessa on vielä exchange jonka databaset on tuolla järjestelmä levyllä. server 2008 r2. missä vika.
Vastaukset 17
Vanhimmat
Vika on isoissa alkukirjaimissa.
MULLA OLIS RUNSAASTI ISOJA ALKUKIRJAIMIA.
Voisin myydä niitä.
Tähän aikaan jo sekopäitä hereillä
Tämä ei kyllä kuullosta ihan aloittelija-tason ongelmalta. Eikä ehkä muutenkaan ongelmalta johon saisit vastauksen Suoli24-palstalta. Kannattanee etsiä foorumi jossa on oikeita asiantuntijoita tällä palstalla vaikuttavien aasintuntijoiden sijaan.
Mutta kysymys oli kyllä esitetty aloittelijamaisella kielellä riittävän sekavasti.
Softa-RAID (tai vastaava lelu-systeemi)? Tuo yhdistettynä hitaaseen levyyn joka sata-pohjainen niin tuolla tavalla se voi toimia. Ja Exchangen kannat rasittavat levyjä tuon lisäksi, jos postiliikennettä palvelimelle on runsaasti ja sen lisäksi jos spam/virus-suodatus tehdään tuolla samalla palvelimella.
Tuon sun sepustuksen perusteella kuulostaa siltä, että systeemiä on ollu rakentelemassa joku serkun kaiman veli, ei oo oikeesti tienny, mitä tekee.
Ja tuossa sun postissa ei ollu tietoa levy-kokoonpanoista. eli ei voi kuin arvailla.
ei ole raidia vaan levy rikoilta suojaudutaan dfs tiedostojärjestelmän avulla sekä kopioimalla järjestelmä varmuuskopiot toisille kiintolevyille tai ristiin eri palvelinten välillä.
suoraan kiintolevyt sata pistokkeilla emolevyssä kiinni. ongelma palvelimessa on 2x wd 500gb toinen hyper-v virtuaali palvelimien virtuaalilevyille ja toisessa on varmuuskopioita, sitten 1x wd 1tb jossa on järjestelmä, exchangen databaset ja muuta dataa, sitten 1x seagate 2tb jossa on käyttäjien dataa ja exchangen transactional logit.
exchangessa ei ole paljon posti liikennettä korkeintaan muutama sata viestiä päivässä en usko että se jatkuvasti voi rasittaa niin paljon. virus ja spam suodatus kuten kaiki muu tehdään tällä palvelimella ei ole muita exchange palvelimia.
Mikä on noiden hitaiden levyjen tarkka malli ja teoreettinen siirtonopeus? Mitä esim. Resource monitor näyttää levykuormituksessa, prosessorikuormassa ja muistin käytössä kun kopiointi menossa, minne tehot katoaa? Onko Event Viewerissä disk-erroreja? Onko hitaus sama suuria ja pieniä tiedostoja kopioitaessa? Käykö näin minkä tahansa tiedostotyypin kanssa? Mitä niillä virtuaalikoneiden levyillä tehdään?
Tuo spammi-suodatus voi viedä paljonkin resursseja, jos palvelimelle tulee paljon roskapostia. Samoin virustorjunta syö nopeasti resursseja, etenkin jos samalla skannataan sekä verkon että kiintolevyjen data-virtoja. Samoin esim. Exchangea ei sais asentaa dc-koneelle, dc:llä suosituksena korkeintaan dchp, dns, wins.
hitaan+levyn+malli+on+wdc+wd10ezex-00bn5a0+.+teoreettinen+siirton+opeus+on+ilmeisesti+6gb/s.+kun+kopiointi+käynnissä+windows+työasemasta+320gb+tiedosto+niin+nopeus+kopiointi+ikkunassa+on+16mb/s.+
Kattelin äkkiä, että tuon levyn nopeus jossain 50 - 150 MB/s välissä. Tuo blue sarja tarkoitettu työasemiin, ei palvelimiin. Eli ilmeisesti sekä emolevyn ohjain ja kiintolevy tukehtuu käytössä. Samoin se ekassa postissa mainittu write-cachen poisto hidastaa levyjen käyttöä. Tuo resource-monitorin jonon luku-arvo kertoo suoraan, että rauta tallentaa todella hitaasti. Oletko tarkistanut tuolta resource-monitorista, mitkä kaikki prosessit järjestelmää kuormittaa? Veikkaan, että yhtenä on f-secure, etenkin jos se myös työasemissa ja asetukset säädetty tarkistamaan myös verkkolevyjä.
Perus-sata pohjaisia systeemeitä ei ole tarkoitettu monen käyttäjän/ohjelmiston ajoon, siinä kohtaa pitäis jo käyttää raid-järjestelmiä nopeuttamaan levyjen käyttöä. Lisäksi käytöön kunnon raid-ohjain. Tai sitten vaihdetaan levy-tekniikkaa ja ohjaimia nopeampaan (sas/ssd).
Tuo muishin varaus exchangen kautta hidastaa kopiointia entisestään, koska exchange ei vapauta muistia tiedosto-välimuistiksi.
Ja jos organisaatiolla varaa ostaa oma Exchange client lisenssit niin ihmettelen suunnattomasti, miksei ole varaa Windows Server lisenssiin. Lisäksi kun nykyiset server-lisenssit sisältävät virtualisoituna 2 server-lisenssiä. Ja jos kerran kuormitusta ei ole, niin miksi sitten kyselet, kun järjestelmät hidastelevat? Tuohan ihan tuosta asennetusta kokoonpanosta johtuva oire. Kahdella 3-5 k€ palvelimella tuo pyörii kauniisti virtualisoituna ja vikasietoisena seuraavat 10 vuotta. IT-puolella kun kannattaa muistaa, että on tyhmää maksaa liian vähän, kustannukset kun tuppaa tulemaan muuta kautta moninkertaisina takaisin.
Niin jos sen levyn nopeus olisi vaikka yli 50 mb/s niin ei mitään ongelmaa mutta kun se on alle 20 mb/s! ja toisille kiintolevyille missä write caching on päällä nopeus myös kirjoitussuunnassa pyörii siellä yli 80-150mb/s ja ei mitään ongelmaa siinäkään. joten ei ainakaan levyn ohjain voi tukehtua mihinkään.
miten small business server voi toimia jos exhcange ei voi olla samalla palvelimella kuin dc? ei siinä ole ollut mitään ongelmaa toiminnan kanssa. lisenssejä olisi yksi "vapaana" exchangen siirtoon virtuaalipalvelimeen mutta se pitäisi laittaa toiseen fyysiseen palvelimeen ja siihen lisätä ensin muistia.
tuota operaatiota olen miettinyt mutta olen todennut että parempi antaa olla sorkkimatta kun siinä sitten kuitenkin sattuu ja tapahtuu kaikenlaista ja ongelmia tulee.
f-secure on työasemissa mutta se ei tarkista verkkolevyjä ainoastaan reaaliaikainen tarkistus ja kerran viikossa työasemien ajoitettu tarkistus.
kun samassa palvelimessa on kolme muuta levyä jotka ei ole järjestelmä levyjä ja werite caching on päällä niin kirjoitus nopeus kaikkiin on jopa yli 100mb/s. ja osa niistä on vanhempia kuin tuo ongelma levy.
ja normaalisti käyttäjien kaikki data on muilla levyillä tuolla järjestelmä levyllä on vain yksi dataosio jossa on harvemmin käytettyjä juttuja ja siihen ei ole käyttäjillä edes kirjoitus oikeuksia vain lukuoikeudet. ja lukunopeudet siinäkin on kunnossa.
käyttäjien datat on levyllä joka toimii normaalisti eikä tätä ongelmaa ole tullut edes esiin vuosikausiin vaikka on varmasti ollut olemassa. nyt tämä tuli vain esiin kun tein acronis boot cd:n jolla yritin ajaa varmuuskopioita tuolle levylle mutta se ei onnistunut ja rupesin ihmettelemään missä vika.
uskaltaako sen write cachingin laitaa päälle vaikka on dc. siinä on kai ad tietokannan korruptoitumis riski. palvelimilla on kyllä ups mutta hallittu sammutus ei ole käytössä koska upsissa riittää virta noin vartiksi. ja palvelimen sammutus kestää niin kauan että se pitäisi käytännössä aloittaa heti kun sähköt on ollut minuutin poissa ja silloin koko ups olisi ihan hyödytön.
eli jos tulee pidempi katko niin kun ups on tyhjä niin palvelimet sammuu kuin veitsellä leikaten.
Tuotteena SmallBusiness Server on eri asia kuin 2008 r2. Eli ne tuotteet on konfiguroitu aivan erilaisella tavalla. Smallbusiness serverissä palveluita, jotka kuristavat ohjelmistojen toimintoja ja mm. vahtivat lisenssiöintiä.
Noissa blue-sarjan ja yleisesti kuluttaja-sarjan levyissä ongelma tulee eteen heti, kun samalle levylle tulee useampia yhtäaikaisia tallennuksia. silloin siirtonopeus pahimmillaan alle 1 MB/s. Teoreettinen sata3 väylän nopeus kullä nopeuden kestää, mutta jos samassa ohjaimessa kiinni 4 levyä, niin maksiminopeus alkaa olla jotain 150 MB/s / levy luokkaa. Mitä enemmän noita tallentavia ohjelmistoja on, sen enemmän systeemi hidastuu. Sulla vielä tuo DFS, sen indeksoinnit ym. mitkä resursseja syövät.
Tuo F-secure, onko reaaliaikaisessa tarkistuksessa verkko-asemien tarkistus päällä? Näin ainakin on ohjelmistossa oletuksena aikaisemmin ollut. Tuota ei nää sovelluksen asetuksista, mutta esim. F-securen policy-managerilla tuota voi säätää.
Sammutus-nopeus, tee scripti, joka ensin sammuttaa Exchangen, vasta sitten palvelimen. Palvelin sammuu silloin huomattavasti nopeammin.
Jos DC:stä system State backup, niin kanta helppo palauttaa. Onko useampaa DC:tä? Jos on, niin silloin kanta useammassa paikassa. Ja en muista itse, koska oisin tuon vuoksi joutunut AD:tä palauttamaan, todennäköisyys korruptiolle minimaallisen pieni. Ok, ymmärtäisin varovaisuuden tuhensien käyttäjien järjestelmässä, mutta pienissä kun tuonne AD-kantaan ei tule paljoakan muutoksia päivän aikana.
Ja tuo Acronicsen bootcd, siinä eri ajurit kuin käyttöjärjestelmässä, se voi vaikuttaa nopeuteen. Mutta suurin syy tuo write-cache, samoin jos levyillä sisäinen välimuistin eri kokoa, niin voi vaikuttaa paljonkin nopeuteen. Ja WD:nkin levyissä, jos käytössä red tai black niin nopeusero huomattava.
Ja vielä tuosta Exchangesta, se varmaankin 2010 versio? Siinä palvelinpohjainen postikantojen sisällön indeksointi. Samoin outlook anywhere ja OWA aiheuttavat iis: kautta kirjoitus-operaatioita levylle, jos tuo iis tuolla ongelma-levyllä.
levyn nopeus 150mb/sek on kyllä ihan riittävä että ei jää siitä kiinni, eihän verkkokaan tuo kuin maksimissaan 100mb/sek ja työasemien levytkään ei välttämättä niin nopeasti pyöri.
mahtaakohan ne dfs ym kirjoittaa koko ajan levylle vaikka juuri silloin kaikki tiedostot olisi synkronissa. tietysti jos käy katsomassa niin palvelimissa kiintolevyn merkkivalot vilkkuu hyvinkin ahrekasti jatkuvasti, tietysti päivisn kun niitä katsonut niin onhan siellä käyttäjiäkin.
kyllä f-secure reaali aikaisesti tarkistaa verkkolevytkin jos käyttäjät sieltä jotain ottaa mutta ei ne niitä skannaile läpi mitenkään ajastetusti. ja noin se saakin olla.
pitäisi kokeilla tuota sammutus aikaa noin mutta siltikään en tiedä kannattaako alkaa automaattiseen sammutukseen koska sähkö voi palata silloin kun se on sammumassa ja siten turha sammutus. ja lähteekö se sitten uudelleen käymään jos sähköt ei välissä katkea eli ups akku kestää mutta automaattinen sammutus on alkanut on myös yksi kysymysmerkki.
dctä on kolme kappaletta joista yksi eri paikassa joten kaikista kolmesta ei kyllä samanaikaisesti voi sähkö katketa käytännössä mitenkään. eli siis jos yksi korruptoituu niin se lähtee toisten avulla uudelleen ns. tulille? tapahtuuko automaattisesti vai joutuuko itse räpläämään.
paitsi siinä missä on kaksi ja varsinainen "pääpaikka" niin työasemille ei jaeta dns ja wins palvelimen osoitteiksi ollenkaan niitä sivupaikan dcssä olevia. sivupaikassa kyllä jaetaan myös pääpaikan osoitteet.
tuolla acronis boot cd:llä kun yritti tallentaa varmuuskopiota hitaalle levylle niin palvelin käytti kaiken keskusmuistin ja kyllä exchangekin antoi lähes kaiken pois ja sitten koko palvelin meni ihan jumiin. vedin varmuuskopio koneesta verkkokaapelin irti ja sitten meni vielä vartti että palvelin alkoi normalisoitua.
mutta jos esim. windows koneesta kopioi isoa tiedostoa niin palvelin toimii normaalisti mutta kopiointi vaan on hidas. tuo acronis jumiutti koko palvelimen pitkäksi aikaa! myöhemmin tein varmuuskopion toiselle levylle samassa palvelimessa (seagate 2tb) ja se meni normaalisti nopeudella 60-70mb/sek.
exchange on 2010 sp 3 ja owa sekä outlook anywhere toimii molemmat hyvin ja nopeasti. paitsi joka kerta kun palvelin on käynnistetty uudelleen eism. päivitysten jälkeen ensimmäisellä kerralla owa lähtee hitaammin auki ja etenkin asetukset osio. mutta kerran kun käy klikkailemassa siellä kaiken läpi niin jatkossa toimii nopeasti kunnes taas käynnistetty uudelleen. ja kyllä on iis samalla levyllä.
ehkä pitää ottaa se write-caching käyttöön kun ei käyttäjiäkään ole paljon ja ups kuitenkin olemassa. ja aika harvoin sellainen sähkö katko tulee että ups menee tyhjäksi itse asiassa en edes muista että niin olisi käynyt.
Pieni tarkennus nopeuksiin, eli jos käytin isoa B puhuin tavuista, pieni b bittejä. Jos verkko 100 Mbit/s niin silloin siirtonopeus verkon kautta teoreettinen max. 12,5 MB/s, todellisuus noin 10 MB/s.
F-Secure muistaakseni edelleen toimii niin, että jos käyttäjä avaa hakemiston, kaikki hakemistossa olevat tiedostot skannataan, eli aiheuttaa paljon kuormaa palvelimille. Voit tuota testata tekemällä EICAR-testimerkkijonosta esim. testi.exe tiedoston ja tallenna se johonkin verkkojaon hakemistoon. Jos hälytys tulee, hakemistoon mentäessä, niin käy kaikki tiedostot läpi (tietenkin kohdistuen tarkastukseen valittuihin tiedostopäätteisiin)
Nuo DC:t replikoivat muutokset käynnissä olevilta. Tuo korruptio vaatisi varsinaisen tietokantatiedoston korruptiota, ainoat kerrat, jolloin olen tuohon törmännyt on vialliset levyt / levyohjaimet. Jos yksikin DC ehjä, voi aina tarvittaessa asentaa uuden DC-koneen.
Tuo palautuksessa tapahtunut hidastus oikein radikaali hidastus melko varmaan johtui Acronicsesta. Jos Exchangekin vapautti muistia urakalla, väitän, että kone alkoi swappaamaan, eli alkoi käyttämään kiintolevyä muistina. Tuo muuten voi olla myös yksi syy hitauteen, jos tuo näennäismuisti sijaitsee tuolla hitaalla levyllä. Silloin koneen keskusmuistin määrän nostamisen pitäisi helpottaa tilannetta. Samoin swapin siirtäminen muualle.
Tuosta Exchangesta, yksinkertaisin tapa saada se pois dc-koneelta on poistaa dc-rooli palvelimesta ja asentaa rooli uuteen palvelimeen. Silloin ei tarvitse Exchangen tavaroita / asetuksia yms. siirtää toiseen järjestelmään. Samoin silloin saisi aikaiseksi ideaali-tilanteen siinä mielessä, että olisi vähintään yksi dc, joka ei sisällä muita palvelintuotteita.
Tuo ups-sammutus, yksi tapa saada koneet takaisin päälle on käyttää wol:ia. esim. seuraavasti. Yksi kannettava kone upsin takana(pysyy päällä pitkään), joka saa myös upsilta tiedon, onko sähköverkko kunnossa. Siellä ajastettu scripti, joka katsoo sähköverkon ja upsin tilan ja sitten tarvittaessa ajaa koneet wollilla päälle. Tuohon vain pitäisi rakentaa sopiva viive, ettei koneet lähde heti päälle kun sähköt tulevat takaisin. Yleensä jos katkos pitkä, virtojen palatessa tulee uusi katkos,
Niin minä puhuin koko ajan tavuista ja verkko on siis gigabit ethernet niin eikö se silloin tuo 100mb/sek.
en tiedä mitä acronis oikein teki mutta jumiin se sen sai. siis tarkennan että acronista ei käytetty tuolla palvelimella vaan eräässä työasemassa josta oli tarkoitus ajaa täydellinen image palvelimeen säilöön. ja se onnistui myöhemmin toiselle levylle samassa palvelimessa.
exchangen store.exellä oli silloin vain pari sataa megaa muistia kun normaalisti sillä on vähintään muutama giga. tarkistin swapin ja tosiaan sitä oli myös hitaalla levyllä mutta myös muilla levyillä. otin kokonaan pois hitaalta levyltä mutta en ole vielä käynnistänyt uudelleen jonka se ilmeisesti vaatii ennenkuin uudet asetukset tulee käyttöön.
olen ymmärtänyt että jos exchange on asennettuna domain controlleriin niin se pitäisi poistaa ensin ennenkuin tekee mitään dc:lle ja sitten asentaa uudelleen. ja dc:n pitää olla myös gc jos siinä on exchange. jos pientä tietokantaa, dfssää, tiedosto ja tulostuspalveluita sekä hyper-v:tä ei lasketa niin silloin täällä on yksi dc jossa ei ole muuta.
ja tuolla sivupaikassa on myös dc jossa on sen lisäksi vain dfs, dns, wins, dhcp ja tietysti normaali tiedosto/tulostuspalvelin. tuossa ups hommassa niin en oikein tykkää ajatuksesta että joku läppärin raato pitäisi johonkin laittaa huolehtimaan palvelimien käynnistyksestä.
tietysti upsiin voisi myös lisätä akkuja (käytännössä siihen voi laittaa niin monta lisäakkuboksia kuin haluaa) mutta siihen ei ole oikein perusteita kun en muista edes että virta olisi koskaan loppunut kun katkoja ei ole ollut ja sitten niitä pitää kuitenkin vaihtaa säännöllisin väliajoin ja mitä enemmän niin sen enemmän aina vaihdettavia akkuja.
mitekähän se jos yksi dc korruptoituu niin onko riskiä että replikointi toimii myös niinpäin että se tuhoaa toimivat. systembackup on otettu molemmista täällä olevista, tuon yhden sivu dc:n ei ole mitään varmuuskopioita koska en ole katsonut tarpeelliseksi. tosin koskaan ei ole mitään varmuuskopiota tarvinnut eikä edes yritetty palauttaa joten ei ole varmuutta toimiiko ne.
data varmuuskopioituu dfs kautta ja sitten myös sen lisäksi otetaan erillisille kiintolevyille varmuuskopiot.
Tuo ups-juttu. Lähinnä ongelmana aina se, että jonkun pitää palvelimet käynnistää, jos koneet on automaattisesti sammutettu. Siksi tuo läppäri-tapa yksi mahdollisuus. Jos pääkäyttäjät saavat tiedon katkoksista esim. sähköpostiin tai teksiviestinä, voi pääkäyttäjä etäältä palvelimen käynnistää. Etenkin jos palvelimissa hallintapiiri, johon pääsee etäältä kiinni vaikka kone olisi sammutettu.
Tuo Exchange AD, oot ihan oikeassa, mää olin tuon jo unohtanut. Eli DC-roolia ei voi poistaa, joutuu aika paljon sen jälkeen askartelemaan, että saa exchangen uudelleen käyntiin. Eli helpoin tapa siirtää palvelin on asentaa uusi exchange ja siirtää postilaatikot sekä mahdollisesti käytössä olevat public-folderit (public folderien siirto kestää mahdollisesti pitkään). Samoin tuossa joutuu huomioimaan muuttuvat ip-osoitteet yms. ellei sitten muuta tuon vanhan koneen osoiettta joksikin toiseksi ennen exchangen asennusta. Tuossa ehkä kannattaa myös harkita palvelin-version vaihtoa, jos mahdollista, eli esim. päivitystä 2016-versioon.
Tuo AD-korruptio, jos se pääsee tapahtumaan, niin kyseisessä koneessa AD ei enää käynnisty. Eli korruptio ei pääse leviämään. AD:ssa kaikissa tapahtumissa aikaleima, kone käynnistyessään replikoi puuttuvat muutokset muilta dc-koneilta. Eli jos korruptoituneen tietokannan palauttaa systemstate varmistuksesta, nousee ad uudelleen päällä. Ja tässä kohtaa tuo Exchangen mukana dc-koneella olo voi tuottaa hankaluuksia. Ja yleisesti DC-koneista, kaikkien dc-koneet kannattaa nykyään tehdä GC-roolin haltioiksi, siitä ei ole periaatteessa mitään haittaa. Aikoinaan tuo erillinen GC-määritys perustui lähinnä suurten verkkojen kuormitus ja roolitus-jakoihin, mutta pienissä verkoissa tuolla ei ole merkitystä.
DFS-replikaatio taas toimii toisella tavalla, eli siellä korruptoitunut tiedosto voi replikoitua muille koneille. Mutta jos tiedostoista varmistukset otettu tarpeeksi usein (riippuu organisaation tarpeista), voi varmistuksista palauttaa vioittuneen tiedoston takaisin.