Microsoft heeft bekendgemaakt dat Exchange 12 alleen verkrijgbaar zal zijn voor 64bits-systemen. Het deed deze aankondiging op het European IT Forum 2005 dat deze week in Barcelona gehouden wordt. De 64bits-beperking zal overigens niet alleen gelden voor Exchange, maar volgens Samm Distasio, verantwoordelijke in de Windows Server Group, zullen alle belangrijke releases van toekomstige serverproducten een 64bits-platform vereisen. De aankondiging gebeurde samen met de voorstelling van de tweede bètaversie van de High Performance Computing Cluster-software, die ook al ontworpen is voor 64bits-systemen. Windows Longhorn Server, gepland voor 2007, zal overigens wel nog in een 32bits-variant verschijnen, maar Release 2 die omstreeks 2009 gepland staat, zal uitsluitend op 64bits-platformen draaien. Andere software die beperkt zal zijn tot een platform met 64bits-mogelijkheden is Longhorn Small Business Edition en de producten uit het Centro-gamma.
Exchange 12 exclusief voor 64bit-processors
Lees meer
Microsoft maakt Centro-plannen concreet
Nieuws van 8 november 2007
Beta 2 van Windows Server Longhorn bijgewerkt
Nieuws van 16 september 2006
Microsoft onderzoekt hoe Exchange-beheer eenvoudiger kan
Nieuws van 23 juli 2006
MS demonstreert remote computing met Longhorn Server
Nieuws van 20 juni 2006
Bèta Exchange 12 voegt 'Unified Messaging' toe
Nieuws van 15 december 2005
Microsoft Command Shell onder de loep gelegd
Nieuws van 26 oktober 2005
Eerste virussen voor nieuwe Microsoft-shell opgedoken
Nieuws van 5 augustus 2005
Microsoft stelt eerste versie shellomgeving beschikbaar
Nieuws van 18 juni 2005
Exchange-roadmap vervolgt zijn bochtige weg
Nieuws van 20 januari 2005
Reacties (67)
:strip_exif()/u/14668/fs.gif?f=community){kind=small}
Ter aanvulling, even wat opmerkelijke info van webwereld geplukt:
'Exchange op 64-bit hardware levert een vermindering van 75 procent van het aantal schrijfacties per seconde vergeleken met dezelfde Exchange op 32-bit hardware', aldus Bob Muglia, baas van Microsofts Server en Tools-divisie.
Het aantal gebruikers per server kan hierdoor bijna verviervoudigd worden bij een gelijkblijvende serverbelasting. Volgens Muglia kan de gebruiker hierdoor de kosten voor opslag per gebruiker met ongeveer 80 procent verminderen.
Support
Volgens Eileen Brown, een IT Pro Evangelist bij Microsoft Engeland, blijft Microsoft de 32-bit versies van Windows nog tot 2017 ondersteunen, daarna alleen nog via aparte contracten.
'Exchange op 64-bit hardware levert een vermindering van 75 procent van het aantal schrijfacties per seconde vergeleken met dezelfde Exchange op 32-bit hardware', aldus Bob Muglia, baas van Microsofts Server en Tools-divisie.
Het aantal gebruikers per server kan hierdoor bijna verviervoudigd worden bij een gelijkblijvende serverbelasting. Volgens Muglia kan de gebruiker hierdoor de kosten voor opslag per gebruiker met ongeveer 80 procent verminderen.
Support
Volgens Eileen Brown, een IT Pro Evangelist bij Microsoft Engeland, blijft Microsoft de 32-bit versies van Windows nog tot 2017 ondersteunen, daarna alleen nog via aparte contracten.
Ik kan met natuurlijk vergissen, maar wat hebben schijfbewerkingen te maken met de processorarchitectuur?
@Wouter Tinus:
Maar wie adresseert op dit moment zoveel geheugen dan dat dit zoveel winst moet halen?
@Wouter Tinus:
Maar wie adresseert op dit moment zoveel geheugen dan dat dit zoveel winst moet halen?
:strip_exif()/u/818/we33ee45.gif?f=community){kind=small}
De stap van 32 naar 64 bit stelt de processor in staat om veel meer geheugen linear te adresseren, van maximaal 4GB naar (op dit moment) 1TB, wat in toekomstige implementaties nog uitgebreid kan worden naar 16EB (exabyte). Met een sloot extra geheugen in de server wordt de harde schijf natuurlijk minder belast, omdat de hele maildatabase gewoon in het RAM geladen kan worden. Nu zijn er ook wel trucs om met een 32 bit processor meer dan 4GB geheugen te gebruiken, maar dat is een kleine ramp voor programmeurs en als het niet heel slim geïmplementeerd wordt kost het alleen maar prestaties.
.
Bedrijven die tientallen of honderden werknemers hebben, met ieder hun eigen mailaccount waarin berichten standaard een jaar bewaard worden o.i.d. Microsoft zal ongetwijfeld 'gunstige' omstandigheden hebben gekozen voor die benchmark, maar databases van 4GB+ zijn an sich helemaal niet zo ongewoon meer. Tweakers.net zit er ook allang overheenMaar wie adresseert op dit moment zoveel geheugen dan dat dit zoveel winst moet halen?
.
En de updates in die extreem grote ram-based database hoeven uiteraard nooit naar schijf geschreven te worden ?
En ja dit kan dan in gegroepeerde, delayed bewerkingen. Maar feit blijft dat ze geschreven moeten worden.
Bottom line is dat je het probleem eigelijk gewoon verschuift. Plus dat je een extra risico creeert want wat als de hardware plots finaal onderuit gaat ? Je hele ram-based database weg, inclusief alle updates van de laatste seconden/minuten.
En wat moet er gebeuren om dat aan te kunnen ? Extra hardware en/of nog meer extra voorzieningen in software.
64bit heeft allerhande voordelen welke goed hun nut kunnen gaan bewijzen, maar het is geen tovermiddel dat er ineens voor kan zorgen dat 100 disk-bewerkingen van vroeger ineens herleid kunnen worden door 2 bewerkingen.
En ja dit kan dan in gegroepeerde, delayed bewerkingen. Maar feit blijft dat ze geschreven moeten worden.
Bottom line is dat je het probleem eigelijk gewoon verschuift. Plus dat je een extra risico creeert want wat als de hardware plots finaal onderuit gaat ? Je hele ram-based database weg, inclusief alle updates van de laatste seconden/minuten.
En wat moet er gebeuren om dat aan te kunnen ? Extra hardware en/of nog meer extra voorzieningen in software.
64bit heeft allerhande voordelen welke goed hun nut kunnen gaan bewijzen, maar het is geen tovermiddel dat er ineens voor kan zorgen dat 100 disk-bewerkingen van vroeger ineens herleid kunnen worden door 2 bewerkingen.
Een RAM-database gebruik je natuurlijk voor je leesbewerkingen, niet voor wijzigingen of toevoegingen. Lezen komt over het algemeen vele malen vaker voor dan schrijven, dus ja, dat kan een hoop schijfbewerkingen schelen zonder extra risico.
Dus jij gaat 4+gig aan ram in je bak proppen enkel en alleen om een mailserver de kans te geven zijn hele mailbase erin te laden in een poging de boel te versnellen ?
Ik krijg de indruk dat het meer gaat over een poging om Exchange bruikbaarder te maken dan dat het een overal tendens is... Want welke non-Windows based mailserver *eist* 64bit en 4+gig aan dedicated ram omdat het anders traag gaat ?
Want wat Microsoft nu eigelijk in mooie bewoording zegt is dat eender welk 32bit platform nooit echt geschikt was voor hun Exchange oplossing ?
Waarom moet voor Microsoft steeds de hardware geoptimalizeerd worden voor hun software ipv. dat ze zelf hun software eens deftig optimizen voor bepaalde hardware ?
Ik krijg de indruk dat het meer gaat over een poging om Exchange bruikbaarder te maken dan dat het een overal tendens is... Want welke non-Windows based mailserver *eist* 64bit en 4+gig aan dedicated ram omdat het anders traag gaat ?
Want wat Microsoft nu eigelijk in mooie bewoording zegt is dat eender welk 32bit platform nooit echt geschikt was voor hun Exchange oplossing ?
Waarom moet voor Microsoft steeds de hardware geoptimalizeerd worden voor hun software ipv. dat ze zelf hun software eens deftig optimizen voor bepaalde hardware ?
Waarom niet? De "640kb is genoeg voor iedereen" tijd ligt ondertussen al ver achter ons. Als meer geheugen meer performance oplevert zal ik het zeker overwegenDus jij gaat 4+gig aan ram in je bak proppen enkel en alleen om een mailserver de kans te geven zijn hele mailbase erin te laden in een poging de boel te versnellen ?
Geen één. Maar welke non windows based mailserver kan flink profiteren van meer dan 4+ gig geheugen. Alle vergelijkbare producten. Zodra ze gebruikt worden voor zulke grote groepen gebruikers als exchange en dezelfde functionaliteit bieden heb je gewoon veel geheugen nodig.Want welke non-Windows based mailserver *eist* 64bit en 4+gig aan dedicated ram omdat het anders traag gaat ?
Maar harddisks zijn traag, dus wil je cachen. Lijkt mij niet zo vreemd. Wel moet je inzien dat Exchange iets anders is dan een simpele Pop3 server. Waarbij gebruikers een Pop3 server zo nu en dan even benaderen om hun gegevens te downloaden, zijn Exchange gebruikers continue verbonden en kunnen zowel de client als de server updates initialiseren. Ook gaan de geleverde diensten wat verder dan enkel mail. Een vergelijkbaar product is Lotus Notes. En ook dat vreet geheugen.
Nee, wel dat veel gebruikers veel data bewaren en tegen de beperkingen van de 32bits architectuur aanliepen. Voor deze gebruikers is er dus een hoop te winnen. Microsoft past Exchange nu aan zodat deze gebruikers veel extra performance krijgen, maar dat betekend wel dat het geheugengebruik van Exchange nóg verder toeneemt. Dat is een probleem met 32bits software maar geen probleem met 64bits software. Dus eist MS voor exchange een 64bits omgeving. Exchange 12 is dus misschien ongeschikt voor 32 bits, maar dat zegt niets over zijn voorgangers. Kiezen voor 64bits systemen waardoor de performance verbetert noem ik toch echt de software optimaliseren voor bepaalde (64bits) hardware.Want wat Microsoft nu eigelijk in mooie bewoording zegt is dat eender welk 32bit platform nooit echt geschikt was voor hun Exchange oplossing ?
:strip_icc():strip_exif()/u/8430/logo.jpg?f=community){kind=logo}
Je gaat voorbij aan wat praktijktesten van Microsoft hebben aangetoond. Dat Exchange 12 op 64-bits hardware 75% minder IO's hoeft te produceren dan Exchnage 2003. Dat is geen toverspreuk maar gewoon een feit.64bit heeft allerhande voordelen welke goed hun nut kunnen gaan bewijzen, maar het is geen tovermiddel dat er ineens voor kan zorgen dat 100 disk-bewerkingen van vroeger ineens herleid kunnen worden door 2 bewerkingen.
Die 'test' heeft MS gedaan ja. Maar hoe objectief kan je die noemen ?Je gaat voorbij aan wat praktijktesten van Microsoft hebben aangetoond. Dat Exchange 12 op 64-bits hardware 75% minder IO's hoeft te produceren dan Exchnage 2003. Dat is geen toverspreuk maar gewoon een feit.
Een vergelijkende test van hn Windows 32 en 64bit versie.
En wat wil die test dan eigelijk zeggen ? Dat ze nu eindelijk eens deftig optimized device drivers voor harddisken gemaakt hebben ?
Want bij eenzelfde software configuratie op een 32 of 64 bit 'verdwijnen' er niet plots een hoop I/O requests. Het systeem kan ze enkel anders gaan afhandelen wat mogelijk voordelen oplevert. Maar verdwijnen doen ze zeker niet.
De catch moet hem dus heel ergens anders zitten, en dat heeft verder weinig te zien met een 32 of 64bit CPU.
Hier zeg je het zelf.Maar welke non windows based mailserver kan flink profiteren van meer dan 4+ gig geheugen. Alle vergelijkbare producten. Zodra ze gebruikt worden voor zulke grote groepen gebruikers als exchange en dezelfde functionaliteit bieden heb je gewoon veel geheugen nodig.
Microsoft eist het om te kunnen werken terwijl non windows based oplossing het absoluut niet eisen, maar wel profijt uit halen.
Dat detail vind ik heel belangrijk.
Microsoft gaat meer en meer de basis van alles voorbij, namelijk rock stable core components maken waar je verder mee kan werken en welke ook mooi scalen op snellere hardware.
En nee dit is geen MS bashing, alleen een vaststelling. Dat ze Exchange gaan upgraden naar 64bit only kan ik nog inkomen, dat ze het nu voordoen alsof 64bit het minimum is om deftig te kunnen werken is grote onzin. Het is niet omdat MS het principe van een groot groupware/mail pakket niet deftig geimplementeerd krijgen op een 32bit systeem, dat ze daarom botweg moeten zeggen dat 32bit te 'simpel' is voor zoiets...
/u/1/femme.png?f=community){kind=small}
De 64bits versie van Exchange kan meer geheugen aanspreken, dus op systemen met veel geheugen (meer dan 2GB) zal Exchange met grotere buffers en caches geconfigureerd kunnen worden. Omdat de data beter gecached kan worden, zullen er minder I/Os op de disks plaatsvinden.En wat wil die test dan eigelijk zeggen ? Dat ze nu eindelijk eens deftig optimized device drivers voor harddisken gemaakt hebben ?
Want bij eenzelfde software configuratie op een 32 of 64 bit 'verdwijnen' er niet plots een hoop I/O requests. Het systeem kan ze enkel anders gaan afhandelen wat mogelijk voordelen oplevert. Maar verdwijnen doen ze zeker niet.
Vrijwel alle nieuwe Windows servers die vanaf volgend jaar verkocht worden, zullen 64bits ondersteuning hebben dus zo ingrijpend is het plan van Microsoft om alleen een 64bits versie van Exchange 12 uit te brengen niet.
@Green.Velvet:
Je bent wel bezig met MS bashing en niet met vaststellingen. Verder laat je merken dat je geen flauw idee hebt hoe Exchange werkt. (of elke willekeurige applicatie met veel data in RAM)
Als je nu goed zou lezen zou je zien dat Pietje Puk aangeeft dat elke applicatie die hetzelfde doet als Exchange dezelfde baat zou hebben als Exchange12.
Dus hij zegt het helemaal niet zelf...
Klagen dat die andere non-windows applicaties geen 64bit vereisen is ook flauwekul want de huidige windows applicatie (exchange2003) vereist het ook niet.
Dus waar blijf je dan met dat belangrijke detail? Het heeft dus niets te maken met de capaciteit van Microsoft om een goede exchange server te maken met 32bits hardware.
Maar voor de toekomst ga je uiteraard wel gebruik maken van superieure hardware. Ook toekomstige concurerende producten zullen het gaan vereisen vanwege precies dezelfde voordelen.
Tegen de tijd dat Exchange12 op de markt is, zijn 64bit servers gemeengoed geworden. Waarom dan zo moeilijk doen als de server applicatie specifiek voor dat betere platform ontwikkeld word?
Wees nou juist blij dat ze het pakket niet hoeven te kortwieken omdat ze perse compatible moeten blijven met 32bits servers.
Dat je met zoveel data in het ram een risico creeert is ook onzin. Net zoals alle applicaties die veel data in het ram schrijven gebruikt exchange transactielogs. Daardoor verlies je dus absoluut geen data tot en met de laatste seconde waarop een crash gebeurd is.
Het enige nadeel hiervan is dat een herstart wat langer duurt omdat je de data in het ram opnieuw opbouwt uit de logfiles, maar de keerzijde is dat je veel betere prestaties krijgt.
Wat betreft rock stable core componenents: In mijn ervaring zijn er weinig Microsoft applicaties die zo stabiel zijn als Exchange. De enige outage die we ooit hebben komt door hardware. (zaken als een SAN notabene).
Microsoft HEEFT het principe van een groote groupware pakket al goed geimplementeerd op 32bits systemen. Alleen kan het nog beter en met minder systemen als je naar 64bits gaat. En dan komt het punt waarom je besluit dat je beter maar helemaal naar 64bits kan overstappen.
Dat is niets bijzonders, en is ook echt niet iets wat alleen voor Microsoft geld. (Ga eens een SAP implementatie doen zonder 64 bits systemen.....Daar krijg je gauw spijt van)
Oh en BTW, je gaat geen 4+ gig aan ram in je bakken proppen om een 4GB database er in te laden.
Een Exchange database van 4GB is peanuts. Daar hoef je niet zoveel ram voor te kopen. Denk eeder aan servers met iets van 200GB aan databases.
En dan hebben we het nog maar over 1500 mailboxen van 200MB per stuk.
Als je nu die servers wil consolideren praat je dus bv over 1TB aan maildata. Is het dan nog zo raar voor je dat je wel wat meer dan 4GB ram wilt gebruiken?
Je bent wel bezig met MS bashing en niet met vaststellingen. Verder laat je merken dat je geen flauw idee hebt hoe Exchange werkt. (of elke willekeurige applicatie met veel data in RAM)
Als je nu goed zou lezen zou je zien dat Pietje Puk aangeeft dat elke applicatie die hetzelfde doet als Exchange dezelfde baat zou hebben als Exchange12.
Dus hij zegt het helemaal niet zelf...
Klagen dat die andere non-windows applicaties geen 64bit vereisen is ook flauwekul want de huidige windows applicatie (exchange2003) vereist het ook niet.
Dus waar blijf je dan met dat belangrijke detail? Het heeft dus niets te maken met de capaciteit van Microsoft om een goede exchange server te maken met 32bits hardware.
Maar voor de toekomst ga je uiteraard wel gebruik maken van superieure hardware. Ook toekomstige concurerende producten zullen het gaan vereisen vanwege precies dezelfde voordelen.
Tegen de tijd dat Exchange12 op de markt is, zijn 64bit servers gemeengoed geworden. Waarom dan zo moeilijk doen als de server applicatie specifiek voor dat betere platform ontwikkeld word?
Wees nou juist blij dat ze het pakket niet hoeven te kortwieken omdat ze perse compatible moeten blijven met 32bits servers.
Dat je met zoveel data in het ram een risico creeert is ook onzin. Net zoals alle applicaties die veel data in het ram schrijven gebruikt exchange transactielogs. Daardoor verlies je dus absoluut geen data tot en met de laatste seconde waarop een crash gebeurd is.
Het enige nadeel hiervan is dat een herstart wat langer duurt omdat je de data in het ram opnieuw opbouwt uit de logfiles, maar de keerzijde is dat je veel betere prestaties krijgt.
Wat betreft rock stable core componenents: In mijn ervaring zijn er weinig Microsoft applicaties die zo stabiel zijn als Exchange. De enige outage die we ooit hebben komt door hardware. (zaken als een SAN notabene).
Microsoft HEEFT het principe van een groote groupware pakket al goed geimplementeerd op 32bits systemen. Alleen kan het nog beter en met minder systemen als je naar 64bits gaat. En dan komt het punt waarom je besluit dat je beter maar helemaal naar 64bits kan overstappen.
Dat is niets bijzonders, en is ook echt niet iets wat alleen voor Microsoft geld. (Ga eens een SAP implementatie doen zonder 64 bits systemen.....Daar krijg je gauw spijt van)
Oh en BTW, je gaat geen 4+ gig aan ram in je bakken proppen om een 4GB database er in te laden.
Een Exchange database van 4GB is peanuts. Daar hoef je niet zoveel ram voor te kopen. Denk eeder aan servers met iets van 200GB aan databases.
En dan hebben we het nog maar over 1500 mailboxen van 200MB per stuk.
Als je nu die servers wil consolideren praat je dus bv over 1TB aan maildata. Is het dan nog zo raar voor je dat je wel wat meer dan 4GB ram wilt gebruiken?
:strip_icc():strip_exif()/u/140051/BSOD.jpg?f=community){kind=small}
Sorry dat vind Ik dus echt een POEP opmerking, vooralWaarom moet voor Microsoft steeds de hardware geoptimalizeerd worden voor hun software ipv. dat ze zelf hun software eens deftig optimizen voor bepaalde hardware ?
je haad hier namelijk totaal voorbij aan enkele harde stelregels die gelden binne de sofware wereld.
een van de belangrijkste daarvan is, denk vooruit,
je ontwikkeld namelijk een systeem waarvan je weet,
dat het niet bedoeld is voor de server-markt op het moment dat je aan het project begint, maar juist, voor het moment dat je verwacht klaar te zijn...
mijn inziens heeft mircrosoft dan ook exact gedaan wat jij zegt. hun software deftig optimaliseren voor bepaalde 64bit hardware
maar sinds tegenwordig, zelfs de gemiddelde 64bit Desktop processor al bijna vaker voor komt in de pricewatch hier op T.net kan ik er ook niet helemaal bij, dat je nog 't idee hebt dat de 32bit servers systemen nog een erg lang leven beschoren zal zijn. aangzien release 2 van longhorn server (2009 / 2010) is geplant kun je er wel safe vanuit gaan dat er dan allang geen 32bit cpu's meer in standaard servers worden verwerkt.
ik zie dan ook voorlopig nog lang geen rede om MS hier op aan te kijken sterker nog, ik vind het zelfs DOM dat Longhorn server uberhapt nog in een 32bit versie zal uitkomen, ik had het persoonlijk veel verstandiger gevonden als ze hun tijd hadden gestoken in een 1 of 2 extra service packs voor windows 2003 server. en anderzijds extra opties voor, longhorn en longhorn server.
Eén van de problemen met de huidige Exchange-servers (2000 en 2003) is dat er contstant tegen de geheugenlimieten van de 32-bits architectuur aan gewerkt wordt. Dat brengt veel nadelen met zich mee, zoals problemen met geheugendefragmentatie, kernel memory fouten, niet TS kunnen draaien op een Exchangeserver, etc. Nu neemt de /3Gb switch een aantal van die problemen weg maar nog steeds zou je met Exchange servers meer geheugen willen gebruiken.Ik kan met natuurlijk vergissen, maar wat hebben schijfbewerkingen te maken met de processorarchitectuur?
In de huidige situatie betekent dit dat je maar een beperkt aantal gebruikers kunt bedienen met een server. Zodra je tegen de limieten aanloopt dan heb je maar een optie: meer servers bijplaatsen. En dat is wat bedrijven liever niet willen, consolidatie is immers wat je wilt.
Dit zijn de belangrijkste redenen waarom is besloten om alleen door te gaan met 64-bit.
Bij het testen van Exchange 12 bij TAP klanten (bedrijven waar vroege versies van technieken getest kunnen worden) bleek al snel dat E12 door het beschikken over meer geheugen veel minder IO's produceerde. E12 produceert ongeveer 75% minder IO's per seconde dan Exchange 2003 en dat betekent dat je dus 4 x zoveel gebruikers kunt bedienen per disk. En aangezien opslag ongeveer 80% van de totale infrastructuur vertegenwoordigd betekent dat een flinke besparing.
Deze Webwerled-quote klopt trouwens niet, dit is een verkeerde interpretatie van wat ik hierboven heb uitgelegd.Het aantal gebruikers per server kan hierdoor bijna verviervoudigd worden bij een gelijkblijvende serverbelasting. Volgens Muglia kan de gebruiker hierdoor de kosten voor opslag per gebruiker met ongeveer 80 procent verminderen.
Waarom vergeet je er bij te vermelden hoeveel RAM er in beide systemen gebruikt werd?E12 produceert ongeveer 75% minder IO's per seconde dan Exchange 2003 en dat betekent dat je dus 4 x zoveel gebruikers kunt bedienen per disk.
Omdat ik dat niet weet. Maar het verschil is inderdaad dat je met 64-bits hardware niet meer de limeit van 4 Gb hebt en daar gaat het nu om.
Wat ik wilde uitleggen is wat Microsoft als volgt zegt:
Wat ik wilde uitleggen is wat Microsoft als volgt zegt:
Ik hoop dat dit wat duidelijker is zo.By taking advantage of the additional memory available on x64-based systems, E12 is able to reduce the IOs per second which results in performance gains.
Dit zegt denk ik meer over de beperkingen van de architectuur van Exchange en het qua performance niet bijster goede programmeerwerk dan over de vernieuwingsdrang van Microsoft. Waar de concurrenten op dit vlak, IBM met Domino en Novell met Groupwise consolidatie weten te bereiken door efficiënter programmeren, waardoor op dezelfde hardware meer gebruikers met meer functionaliteit kunnen werken (ter illustratie, met Domino 7 kunnen op dezelfde hardware 50% meer webmail gebruikers werken met meer functionaliteit en gelijke performance dan op versie 6), blijft Microsoft het zoeken in nog zwaardere hardware en nog hogere (en daardoor beperkende) versies van haar besturingssysteem (ter illustratie, IBM Domino 7 draait naast op Linux, AIX, Solaris en Windows 2003 etc ook nog gewoon op Windows 2000 (en waarschijnlijk zelfs NT 4) zonder beperking van functionaliteit). Het blijft voor mij vreemd dat klanten dit blijven pikken, maar de marketingmachine van Microsoft verslaat blijkbaar de logica.
Het viel me nu pas op wat je hier zegt. Je gaat er hier vanuit dat niet de grootte van de disk bepalend is voor hoeveel gebruikers je per disk kunt bedienen, maar de snelheid ervan. Dat lijkt me een beetje vreemde aanname eigenlijk. Bij die 80% opslagkosten gaat het wel voornamelijk over de diskgrootte (backuppen is niet zo aan snelheid van een disk gebonden namelijk), dus de conclusie is onjuist.E12 produceert ongeveer 75% minder IO's per seconde dan Exchange 2003 en dat betekent dat je dus 4 x zoveel gebruikers kunt bedienen per disk.
I/O is op zware servers een serieus probleem en dan zal het aantal disks echt wel eerder afhangen van de benodigde I/O performance dan van de gevraagde capaciteit. Opslagcapaciteit kost tegenwoordig geen drol meer. Je kunt bij wijze van spreken 1500 Exchange-gebruikers onderbrengen op een server met drie voor servergebruikt geschikte 7200rpm 400GB SATA-harde schijven in RAID 1 + hotspare. De reden dat dit niet gedaan wordt is dat twee 7200rpm schijven in RAID 1 niet de performance bieden om 1500 users te kunnen bedienen. Voor het bereiken van een hogere I/O performance zijn hoogtoerige schijven nodig, het liefst een zo groot mogelijk aantal spindels (dus liever meer schijven met een lage capaciteit dan een kleiner aantal schijven met een hoge capaciteit), en een snelle RAID-controller met een berg cache.Het viel me nu pas op wat je hier zegt. Je gaat er hier vanuit dat niet de grootte van de disk bepalend is voor hoeveel gebruikers je per disk kunt bedienen, maar de snelheid ervan. Dat lijkt me een beetje vreemde aanname eigenlijk. Bij die 80% opslagkosten gaat het wel voornamelijk over de diskgrootte (backuppen is niet zo aan snelheid van een disk gebonden namelijk), dus de conclusie is onjuist.
Ik ben blij dat er eindelijk wat meet 64bit initiatief genomen wordt. Iedereen heeft een 64bit processor maar nog geen 64bit software.
iedereen?!
die paar gamers, ja. De marktaandelen zijn niet "AMD64 - 50%, P4 met 64bit extensies - 50%, rest 0%" !
De overgrote meerderheid heeft nog gewoon 32bit Intel Xeon- Pentium- en Centrino systemen. Dat geldt voor servers werkstations laptops en thuisgebruikers. Dus dat "iedereen" is zoiets als "iedereen heeft een brommer"... geldt alleen voor een heel klein groepje mensen. In het laatste geval 16 jarigen.
die paar gamers, ja. De marktaandelen zijn niet "AMD64 - 50%, P4 met 64bit extensies - 50%, rest 0%" !
De overgrote meerderheid heeft nog gewoon 32bit Intel Xeon- Pentium- en Centrino systemen. Dat geldt voor servers werkstations laptops en thuisgebruikers. Dus dat "iedereen" is zoiets als "iedereen heeft een brommer"... geldt alleen voor een heel klein groepje mensen. In het laatste geval 16 jarigen.
Het gaat in dit verhaal over serversoftware. De door jouw genoemde marktaandelen zijn niet relevant.
In de servermarkt is de 64bit AMD en Xeon penetratie lager dan bij de thuisgebruikers, dus dat versterkt mijn punt alleen maar.
Voorzover ik weet zijn er weinig tot geen games al volledig 64bit geoptimaliseerd, dus waarom je die gamers erbij haalt ontgaat me even.
Nou nee hoor, het is zelfs zo dat het grootste deel nog gewoon op 32bit systemen draait.
Dat maakt het 'opdringen' van 64bit software nog niet slecht.
Dat maakt het 'opdringen' van 64bit software nog niet slecht.
:strip_exif()/u/23403/wicky55.gif?f=community){kind=small}
Iemand die de nieuwste versie van exchange koopt, koopt er ook wel up2date hardware bij. Alles wat je nu koopt is 64 bit, zo'n beetje, dus ik zie dit niet echt als opdringen.
In 2009 hoef je helemaal geen rekening meer te houden met 32bits te houden...
Oude versies van software krijgen nog jaren lang ondersteuning voor oude hardware, nieuwe software mag best uit gaan van hardware die dan standaard is. Kortom, ik snap het besluit van MS wel.
In 2009 hoef je helemaal geen rekening meer te houden met 32bits te houden...
Oude versies van software krijgen nog jaren lang ondersteuning voor oude hardware, nieuwe software mag best uit gaan van hardware die dan standaard is. Kortom, ik snap het besluit van MS wel.
Maar Exchange 12 wordt in 2006 gereleased.In 2009 hoef je helemaal geen rekening meer te houden met 32bits te houden...
Wilde jij dan een in-place-upgrade doen naar Exchange12?
Het gebruikelijker om nieuwe servers neer te zetten met de nieuwe software en de mailboxen te verplaatsen.
(de hardware van je Exchange2000/2003 servers is toch al afgeschreven, of is al 64bits)
Het gebruikelijker om nieuwe servers neer te zetten met de nieuwe software en de mailboxen te verplaatsen.
(de hardware van je Exchange2000/2003 servers is toch al afgeschreven, of is al 64bits)
De meeste notebooks ondersteunen nog steeds geen 64bits. Voor ontwikkelaars is dit dus niet echt handig.
Ook is het niet fijn als je huidige server nog voldoet en je enkel wilt upgraden voor nieuwe features (wat die ook mogen zijn) Er zitten dus wel wat nadelen aan, maar die zullen waarschijnlijk niet opwegen tegen de voordelen van meer geheugen.
Ook is het niet fijn als je huidige server nog voldoet en je enkel wilt upgraden voor nieuwe features (wat die ook mogen zijn) Er zitten dus wel wat nadelen aan, maar die zullen waarschijnlijk niet opwegen tegen de voordelen van meer geheugen.
:strip_icc():strip_exif()/u/88631/qw.jpg?f=community){kind=small}
juh.. maar je gaat IMO ook geen exchange testen op je lappie
:strip_exif()/u/18996/GoT_avatar.gif?f=community){kind=avatar}
Pas vanaf 2009 zal je een 64 bits processor nodig hebben, de amd turion laptops hebben dit al een tijdje en tegen die tijd zal intel ook alle laptops wel met 64 bit uitgerust hebben hoor.
Geloof me maar, over 4 jaar is dat echt geen probleem meer, je ziet al dat ongeveer elke nieuwe computer nu 64 bit is dus over ~1 jaar zal ook ongeveer elke nieuwe laptop wel 64 bit zijn.
Ik vind het overigens ook geen vreemde beslissing van microsoft, zeker bij software als exchange kan er veel voordeel behaald worden door dingen in 64 bits op te slaan in plaats van 32 bits.
Geloof me maar, over 4 jaar is dat echt geen probleem meer, je ziet al dat ongeveer elke nieuwe computer nu 64 bit is dus over ~1 jaar zal ook ongeveer elke nieuwe laptop wel 64 bit zijn.
Ik vind het overigens ook geen vreemde beslissing van microsoft, zeker bij software als exchange kan er veel voordeel behaald worden door dingen in 64 bits op te slaan in plaats van 32 bits.
Ach, die paar ontwikkelaars die daadwerkelijk Exchange op hun laptops moeten hebben die kunnen wel een 64 bits laptop aanvragen.
(overigens geld het helemaal niet alleen voor Exchange maar voor alle applicaties, dus ze zullen zowiezo een 64bits cpu nodig hebben)
(overigens geld het helemaal niet alleen voor Exchange maar voor alle applicaties, dus ze zullen zowiezo een 64bits cpu nodig hebben)
Als je een Linux installatie hebt is al je software 64-bit.
Dus iedereen kan vandaag al met een 100% 64-bit OS werken, waarin alle applicaties ook 100% 64-bit zijn.
Dus iedereen kan vandaag al met een 100% 64-bit OS werken, waarin alle applicaties ook 100% 64-bit zijn.
Dat DENK jij maar.
Dat je je software zelf kunt compileren betekent niet dat het automatisch werkt op 64bits systemen.
In C is namelijk niet defenieerd wat er met een integer gebeurd op een 32bit of 64 bit systeem. Het kan zijn dat dat 64bit systeem dan automatisch je integer ook 64bit maakt, maar het kan ook een 32bit int blijven.
Als de software van een bepaalde waarde van maxint uitgaat (wat vaker gebeurd dan je denkt) dan geeft dat leuke bugs.
Dat je je software zelf kunt compileren betekent niet dat het automatisch werkt op 64bits systemen.
In C is namelijk niet defenieerd wat er met een integer gebeurd op een 32bit of 64 bit systeem. Het kan zijn dat dat 64bit systeem dan automatisch je integer ook 64bit maakt, maar het kan ook een 32bit int blijven.
Als de software van een bepaalde waarde van maxint uitgaat (wat vaker gebeurd dan je denkt) dan geeft dat leuke bugs.
:strip_icc():strip_exif()/u/9208/icon.jpg?f=community){kind=icon}
Ach, tegen de tijd dat het uitkomt, heeft bijna iedereen een 64bits processor, dus waar maakt iedereen zich zo druk om ?
Iedereen maakt zich er zo druk om omdat het dikke onzin is om maar verplicht 64bit te gebruiken. GroupWise draait ook prima met veel gebruikers op 32bit (ook wel op 64bit 
)dus waarom zou het onmogelijk zijn om Exchange op 32bit te draaien.......*i wonder why?*
)dus waarom zou het onmogelijk zijn om Exchange op 32bit te draaien.......*i wonder why?*
Dat bedoel ik dus.
64bit en bijhorende voordelen zijn een feit, maar Microsoft die nu ineens komt roepen dat 64bit het minimum is om 'iets' te kunnen doen is way over the top.
Wat dan met alle non x86 en non windows based systemen die al jaar en dag de meest heavy toepassingen runnen voor banken bijvoorbeeld ?
Volgens MS allemaal n00b systeemjes die maar 32bit ofzo draaien zeker ?
MS leert het gewoon niet af om hun eigen fouten of onkunde steeds op de hardware of de zogenaamde beperkingen ervan te steken...
64bit en bijhorende voordelen zijn een feit, maar Microsoft die nu ineens komt roepen dat 64bit het minimum is om 'iets' te kunnen doen is way over the top.
Wat dan met alle non x86 en non windows based systemen die al jaar en dag de meest heavy toepassingen runnen voor banken bijvoorbeeld ?
Volgens MS allemaal n00b systeemjes die maar 32bit ofzo draaien zeker ?
MS leert het gewoon niet af om hun eigen fouten of onkunde steeds op de hardware of de zogenaamde beperkingen ervan te steken...
MS roept niet dat 64bit het minimum is om Exchange te kunnen draaien. Ze hebben namelijk al met 2003 gedemonstreerd dat het prima op 32bit kan.
Ze hebben er echter voor gekozen om geen dubbele code-base te maken, en allerlei compromissen om zowel op 32bit als 64bit te draaien, maar de zaak eenvoudiger en efficienter te houden door gewoon voor één van de twee te kiezen.
Het geeft meteen de mogelijkheid om verder te gaan met consolidatie van servers, wat een veelgehoorde wens van klanten is.
Ze hadden Exchange12 ook best voor 32bit kunnen maken, maar het is gewoon veel verstandiger om het alleen maar voor 64bits te maken.
Met name als al je klanten daar geen enkel probleem mee zullen hebben, en blij zullen zijn met de extra mogelijkheden die dat biedt.
Zo roepen dus dat ze ervoor gekozen hebben om Exchange12 alleen voor 64bits te maken. Dat is wat anders dan roepen dat het niet zonder 64bits had gekund.
Waarom is dat zo moeilijk te begrijpen?
BTW die non-x86 en non-windows systemen die al die meest heavy toepassingen draaien zijn in de meeste gevallen OOK 64bit. En waarschijnlijk zijn ze dat al vele jaren.
Ze hebben er echter voor gekozen om geen dubbele code-base te maken, en allerlei compromissen om zowel op 32bit als 64bit te draaien, maar de zaak eenvoudiger en efficienter te houden door gewoon voor één van de twee te kiezen.
Het geeft meteen de mogelijkheid om verder te gaan met consolidatie van servers, wat een veelgehoorde wens van klanten is.
Ze hadden Exchange12 ook best voor 32bit kunnen maken, maar het is gewoon veel verstandiger om het alleen maar voor 64bits te maken.
Met name als al je klanten daar geen enkel probleem mee zullen hebben, en blij zullen zijn met de extra mogelijkheden die dat biedt.
Zo roepen dus dat ze ervoor gekozen hebben om Exchange12 alleen voor 64bits te maken. Dat is wat anders dan roepen dat het niet zonder 64bits had gekund.
Waarom is dat zo moeilijk te begrijpen?
BTW die non-x86 en non-windows systemen die al die meest heavy toepassingen draaien zijn in de meeste gevallen OOK 64bit. En waarschijnlijk zijn ze dat al vele jaren.
Het ontwikkelteam heeft gewoon een reden gezien om de nieuwe Exchange voor het 64-bits platform te optimalizeren. Niet vreemd denk ik want ik kan me goed voorstellen dat je compromissen moet doen als je het zowel op 32-bits en 64-bits wilt laten draaien. En misschien weet Microsoft al waar Intel heen gaat de toekomst van Intel's server platform.
De historie herhaalt zich want ook bij de overgang van 16-bits naar 32-bits hoorde ik veel collega programmeurs zuchten en kreunen over een nieuw OS, nieuwe API, nieuwe tools, etc...
De historie herhaalt zich want ook bij de overgang van 16-bits naar 32-bits hoorde ik veel collega programmeurs zuchten en kreunen over een nieuw OS, nieuwe API, nieuwe tools, etc...
"bijna iedereen"
Alsof dat uitmaakt... je gaat deze Exchange echt niet op elke client computer installeren ofzo.
Alsof dat uitmaakt... je gaat deze Exchange echt niet op elke client computer installeren ofzo.
:strip_icc():strip_exif()/u/4421/sas.jpg?f=community){kind=small}
Hahaha, dit is echt slecht!
Heb namelijk afgelopen week lopen testen met Windows Server 2003 Enterprise Edition 64-bit.
Microsofts redelijk recent uitgekomen System Center Data Protection Manager 2006 (DPM 2006) draait niet onder 64-bit versies van Windows 2003 Server, voor installatie krijg je al een foutmelding dat de software dat niet ondersteund.
Net zoals Symantec Backup EXEC v10d ook geen 64-bit OS ondersteunt.
Is dit nou raar of ben ik nou gek?
Laat me niet lachen...
Heb namelijk afgelopen week lopen testen met Windows Server 2003 Enterprise Edition 64-bit.
Microsofts redelijk recent uitgekomen System Center Data Protection Manager 2006 (DPM 2006) draait niet onder 64-bit versies van Windows 2003 Server, voor installatie krijg je al een foutmelding dat de software dat niet ondersteund.
Net zoals Symantec Backup EXEC v10d ook geen 64-bit OS ondersteunt.
Is dit nou raar of ben ik nou gek?
Laat me niet lachen...
:strip_icc():strip_exif()/u/25528/crop6262b474a9363_cropped.jpg?f=community){kind=small}
Net zoals Symantec Backup EXEC v10d ook geen 64-bit OS ondersteunt.
Microsoft is niet verantwoordelijk voor de programma's van andere leveranciers. Dus daar kun je MS moeilijk voor verantwoordelijk houden.
Jij concludeert op basis van 1 programma die je in combinatie met een beta (Exchange 2003) wil gaan draaien dat MS niet goed bezig is met hun serverprogrammatuur. Lijkt mij nogal kort door de bocht.
Verwachting is, dat de komende tijd (paar jaar) meer geporteerd zal gaan worden naar 64-bits.
Is dit nou raar of ben ik nou gek?
Doe ik geen uitspraken over...
Microsoft is niet verantwoordelijk voor de programma's van andere leveranciers. Dus daar kun je MS moeilijk voor verantwoordelijk houden.
Jij concludeert op basis van 1 programma die je in combinatie met een beta (Exchange 2003) wil gaan draaien dat MS niet goed bezig is met hun serverprogrammatuur. Lijkt mij nogal kort door de bocht.
Verwachting is, dat de komende tijd (paar jaar) meer geporteerd zal gaan worden naar 64-bits.
Is dit nou raar of ben ik nou gek?
Doe ik geen uitspraken over...
/u/100867/crop5601ca928ac47_cropped.png?f=community){kind=small}
Volgens mij Maakt MS een operatie systeem dat door 90% van de wereld bevolking wordt gebruikt. Kunen ze dan niet zorgen dat ze wat betere suport leveren.Net zoals Symantec Backup EXEC v10d ook geen 64-bit OS ondersteunt.
Microsoft is niet verantwoordelijk voor de programma's van andere leveranciers. Dus daar kun je MS moeilijk voor verantwoordelijk houden.
btw?
kan windows 64 geen 32bit code draaien?
linux kan dit zonder enige beperking
Kunen ze dan niet zorgen dat ze wat betere suport leveren.
Wie zegt dat het feit dat Symantec nog geen 64 bits versie van Veritas heeft, aan de gebrekkige support van MS ligt? Alle bedrijven weten dat 64 bits besturingssystemen eraan zitten te komen. Ik kan me dus ook niet voorstellen, dat ze bij Symantec achterover aan het leunen zijn onder het motto dat ze nog support van MS verwachten...
Maar ik hoef MS hier niet te verdedigen: ik zie zelf liever ook andere besturingssystemen hoor. Ik reageerde alleen op het feit dat Urk het belachelijk vond dat hij Backup Exec niet kon draaien onder het besturingssysteem van MS en daar per definitie maar MS de schuld van geeft, terwijl Symantec daar misschien toch ook in gebreke blijft (want, zoals eerder gezegd, we weten allemaal dat 64 bits besturingssystemen eraan zitten te komen)...
Wie zegt dat het feit dat Symantec nog geen 64 bits versie van Veritas heeft, aan de gebrekkige support van MS ligt? Alle bedrijven weten dat 64 bits besturingssystemen eraan zitten te komen. Ik kan me dus ook niet voorstellen, dat ze bij Symantec achterover aan het leunen zijn onder het motto dat ze nog support van MS verwachten...
Maar ik hoef MS hier niet te verdedigen: ik zie zelf liever ook andere besturingssystemen hoor. Ik reageerde alleen op het feit dat Urk het belachelijk vond dat hij Backup Exec niet kon draaien onder het besturingssysteem van MS en daar per definitie maar MS de schuld van geeft, terwijl Symantec daar misschien toch ook in gebreke blijft (want, zoals eerder gezegd, we weten allemaal dat 64 bits besturingssystemen eraan zitten te komen)...
:strip_icc():strip_exif()/u/12949/feyenoord.jpg?f=community){kind=small}
Nee, het is niet raar, en ja jij bent gek.
Is Exchange 12 al op de markt? Nee, het product is volop in ontwikkeling. Tegen de tijd dat het daadwerkelijk op de markt is, ondersteunen de door jou genoemde producten ook 64-bit.
Is Exchange 12 al op de markt? Nee, het product is volop in ontwikkeling. Tegen de tijd dat het daadwerkelijk op de markt is, ondersteunen de door jou genoemde producten ook 64-bit.
Hopelijk komt in navolging van de server programmatuur, nu ook de driver support voor 64 bits consumenten producten op gang, dit is namelijk de hoofd reden dat ik nog niet ben overgestapt op een 64bits windows OS.
Want opzich persoonlijk vond ik de 64bits versie van windowsxp beter draaien dan de 32bits versie in combinatie met m'n athlon64 3200+. Alleen dingen zoals activesync kreeg ik maar niet goed aan de praat en aangezien ik m'n pda nogal vaak gebruik, ben ik weer terug gegaan naar winxp 32bit.
Want opzich persoonlijk vond ik de 64bits versie van windowsxp beter draaien dan de 32bits versie in combinatie met m'n athlon64 3200+. Alleen dingen zoals activesync kreeg ik maar niet goed aan de praat en aangezien ik m'n pda nogal vaak gebruik, ben ik weer terug gegaan naar winxp 32bit.
Volgens mij is het vaak ook wel logisch dat nieuwere versies om betere hardware vragen, aangezien er vaak nieuwe opties zijn.
Overigens is het lang niet altijd verplicht, aangezien Ms vaak de recommended systeemeisen stukken hoger stelt dan daadwerkelijk nodig, om een goede werking van het product te garanderen.
Lijkt me toch weer een beetje MS-bashing, de bovenstaande reactie...
Overigens is het lang niet altijd verplicht, aangezien Ms vaak de recommended systeemeisen stukken hoger stelt dan daadwerkelijk nodig, om een goede werking van het product te garanderen.
Lijkt me toch weer een beetje MS-bashing, de bovenstaande reactie...
:strip_exif()/u/155650/bassiegot.gif?f=community){kind=small}
Dit pushen is iets waar webdevelopers al jaren naar smachten, maar dan met de standaard richting MS. Maarja...wij hebben geen monopolie om het door te kunnen drukken...
Toch wel een beetje raar. Eerst wacht MS een eeuwigheid met het uitbrengen van hun 64bits-Windows omdat Intel nog niet klaar is (AMD ligt allaang te wachten) en nu Intel klaar is willen ze het opeens gaan pushen.....
*ps. Aangezien AMD toch iets beter lijkt met 64-bits toepassingen is dit misschien wel een leuke opsteker voor de Opterons (ik ben niet zo technisch in die zaken dus als ik het fout heb mag je me flamen (ook wel eens leuk om daar toestemming voor te krijgen lijkt me zo))
Toch wel een beetje raar. Eerst wacht MS een eeuwigheid met het uitbrengen van hun 64bits-Windows omdat Intel nog niet klaar is (AMD ligt allaang te wachten) en nu Intel klaar is willen ze het opeens gaan pushen.....
*ps. Aangezien AMD toch iets beter lijkt met 64-bits toepassingen is dit misschien wel een leuke opsteker voor de Opterons (ik ben niet zo technisch in die zaken dus als ik het fout heb mag je me flamen (ook wel eens leuk om daar toestemming voor te krijgen lijkt me zo))
:strip_icc():strip_exif()/u/17324/iconlogo.jpg?f=community){kind=small}
De eerste stap naar "sorry, deze hardware wordt niet ondersteund. U dient een (dure) upgrade uit te voeren om nog fatsoenlijk te kunnen werken".
Ok, 't neigt naar een troll, maar kom op, zo gaat het wel gebeuren straks...
Ok, 't neigt naar een troll, maar kom op, zo gaat het wel gebeuren straks...
/u/40481/crop63f777c898038_cropped.png?f=community){kind=small}
is het niet zo met alle MS software dat je toch eerst je hardware aan 't updaten komt? MS heeft er een handje naar om bij ieder nieuw stuk software zwaardere eisen te stellen of het daadwerkelijk verbetering oplevert is nog maar de vraag. Dit onderscheid imo ook sterk de MS/linux/unix cultuur. MS ben je genoodzaakt een nieuwe server tekopen terwijl als er linux/unix software geupdate wordt is dat maar zelden het geval. tevens werk je anders aangezien je pas een nieuwe server koopt wanneer de load te hoog wordt iets wat bij MS services vaak moeilijker te realiseren is.
Ik zie dat toch eerder als een voordeel. De hardware wordt nou eenmaal sneller, 't lijkt me geen foute instelling om te streven naar software die betere hardware ook uitnut.
Daarnaast komt MS nou ook weer niet zo vaak uit met nieuwe (server-)software, met name een OS. Daarnaast verbied niemand je om niet te upgraden, de support op de software is toch meestal een jaar of 10, iig veel langer dan de gemiddelde levensduur van de hardware.
Daarnaast komt MS nou ook weer niet zo vaak uit met nieuwe (server-)software, met name een OS. Daarnaast verbied niemand je om niet te upgraden, de support op de software is toch meestal een jaar of 10, iig veel langer dan de gemiddelde levensduur van de hardware.
Op dit item kan niet meer gereageerd worden.