Chomper

Am 22.3.2019 um 23:56 schrieb PowerShellAdmin:

Mindestens ein Teil der Ursache ist die Thindisk, die Thickdisk ist beim seq q32t1 und 4 KB q8t8 deutlich gestiegen.

 

 

Die Angaben schauen nach CrystalDiskMark aus. Meiner Meinung nach nicht geeignet, um die Performance eines Raid-Verbunds im Bezug auf Datenbank und Exchange  zu messen.

Versuche es doch mal bitte mit Iometer:

http://vmktree.org/iometer/

Z.B. Referenzwerte eines SAN: https://vmware-forum.de/viewtopic.php?t=32249

als SATA SSD ist die 883DC  auch mit V-NAND (3D-TLC) und nicht eMLC ausgestattet.

https://www.anandtech.com/show/13704/enterprise-ssd-roundup-intel-samsung-memblaze/2

Am 3/21/2019 um 09:38 schrieb PowerShellAdmin:

 

Der Storage besteht aus einem PERC H740P mit 8 einfachen Enterprise SSD...

 

Die Raid-Policy würde ich wie folgt avisieren:

• No Read Ahead
• Write Through

 

Wieso bitte Write Through? Das Ding hat 8GB Cache, die so quasi brach liegen. 

Was leider auch in Kombination mit den Windows Search Services nicht geht: Deduplizierung. Also sobald das an ist, macht der Search index nur murks. 

vor 23 Stunden schrieb peterg:

Die Daten liegen auf einer extra VHDx Partition mit fester Größe. Jede VM hat (wenn benötigt) eine extra Datenplatte. Der Fileserver hat eine Datenplatte mit ca. 4 TB (SAS-Platten der SAN) und eine mit 34 TB (SATA-Platten der SAN). Die 34 TB sind notwendig, da aufgrund von bestimmten Kanal-Berechnungen die temporären Berechnungsdateien mehrere TB groß sein können. Hier wollten wir sehr viel Reserve.

 

Kann es sein, dass bei 38 Clients Gigabit nicht ausreicht?

Welches Windows Dateiformat hat denn diese virtuelle 34TB HDD? REFS oder NTFS? Welcher virtuelle VMware-Controller-Treiber wird denn für die vDISK verwendet? LSI oder der oft zickige Paravirtual?

Ist der Server auf dem aktuellen Patch-Stand? Mit dem Juli-Updates gab es Verbesserungen was REFS angeht (im Backup-Umfeld).

Und im Normalfall reichen auch bei 38 Clients Gigabit. Wenn nicht alle parallel Videos bearbeiten oder ähnlich viele GB transferieren. Und wenn gehts dann auch nur temporär langsamer.

Und bei kleinen Umgebungen kostenlos mit den Scripten von Frank Zoechling.

https://www.frankysweb.de/exchange-reporter-2013/

vor 1 Stunde schrieb MOV_EAX,0:

 

Hallo,

 

ich betreue ein kleines Unternehmen, das ein Netzwerk aus Windows 2012R2 und 10 Clients (Win 7) einsetzt. Auf dem Server läuft ein SQL-Datenbankserver. Alle Rechner sind in genau einer Domäne, der Server ist der DC mitsamt GC.

 

Der Ausfall des WaWi wäre für das Unternehmen sehr schmerzlich, da dann der Geschäftsbetrieb zu >90 % unterbrochen ist, viele Dienstleistungen lassen sich nur mit/über dieses WaWi erledigen.

 

Von den Clients ziehe ich regelmäßig Acronis Backups, vom Server aktuell nicht, da der mit Wartungsvertrag von einer Drittfirma unterhalten wird. Die Backups werden nicht im Unternehmen aufbewahrt.

Welche Ausfallzeit definiert denn der Unternehmenschef bzw. Inhaber? 

Was beinhaltet denn der Wartungsvertrag des Servers für Leistungen? Und welches Reaktionszeit ist da definiert? 

Ich werfe nur die Stichworte RTO/ RPO in den Raum. https://de.wikipedia.org/wiki/Disaster_Recovery

Das Konstrukt so funktioniert wohl nur so lange, bis mal was schief läuft.

Was soll überhaupt der Punkt d) "Ich baue eine weitere Platte ein für ein Raid-1" heißen? Hat der Server kein Solches, um wenigstens die Verfügbarkeit bei HDD/SSD Ausfall zu gewährleisten? 

Wie gesagt, zu Klären wäre zuerst, was der Wartungsvertrag alles beinhaltet. Rein Software, Hardware? Welches Reaktionsfenster?

Ist die ERP Software denn für Windows Server 2016 Essential freigegeben? 

Welcher geheime Anbieter ist das denn?

Hast du nicht zumindest nach der zweiten OS Installation vor dem installieren der ERP Software einen Voll-Backup des System gemacht?

Wer hat denn 5 Selbständigen ein System mit 8x8TB Platten, dann auch noch im Raid-5 verkauft? Braucht ihr so viel Platz, sprich 50TB?

Wenn da mal eine ausfällt, dann kann so ein Rebuid gut 1-2 Tage dauern.

Der ERP Anbieter macht es sich da ein wenig zu einfach.

Wenn ein Qnap NAS da ist, würde ich mir Naikvo anschauen. Kann als Appliance auf dem NAS laufen.

https://www.qnap.com/solution/qnap-nakivo/de-de/

Und den Host dann per Windows Server Sicherung ( ohne das Laufwerk mit den VM's bzw. die VM's ansich) oder alternativ mit dem Veeam Agent.

http://www.medic-daniel.de/hyper-v/2014/01/windows-server-2012-r2-backup-hyper-v

Hat schon wer erfolgreich nen optiplex 7010 gepatcht? Ich hab das Windows update installiert, das bios update vom 09.01. installiert, die Registry keys gesetzt und trotzdem der obere Teil des PS-Prüfbefehls rot... da ist doch noch was faul mit dem bios...?!

 

Da das ja ein Q77 Chipsatz für Gen2/3 Core CPUs ist, stellt sich die Frage, wo Dell da MicroCode Updates her haben soll. Laut Intel soll es doch nur ab Haswell Updates geben?

Ich finde ja GOSTEV von Veeam hat das in seinem Forum Letter sehr gut beschrieben, mal anbei als Quote:

 

By now, most of you have probably already heard of the biggest disaster in the history of IT – Meltdown and Spectre security vulnerabilities which affect all modern CPUs, from those in desktops and servers, to ones found in smartphones. Unfortunately, there's much confusion about the level of threat we're dealing with here, because some of the impacted vendors need reasons to explain the still-missing security patches. But even those who did release a patch, avoid mentioning that it only partially addresses the threat. And, there's no good explanation of these vulnerabilities on the right level (not for developers), something that just about anyone working in IT could understand to make their own conclusion. So, I decided to give it a shot and deliver just that.

 

First, some essential background. Both vulnerabilities leverage the "speculative execution" feature, which is central to the modern CPU architecture. Without this, processors would idle most of the time, just waiting to receive I/O results from various peripheral devices, which are all at least 10x slower than processors. For example, RAM – kind of the fastest thing out there in our mind – runs at comparable frequencies with CPU, but all overclocking enthusiasts know that RAM I/O involves multiple stages, each taking multiple CPU cycles. And hard disks are at least a hundred times slower than RAM. So, instead of waiting for the real result of some IF clause to be calculated, the processor assumes the most probable result, and continues the execution according to the assumed result. Then, many cycles later, when the actual result of said IF is known, if it was "guessed" right – then we're already way ahead in the program code execution path, and didn't just waste all those cycles waiting for the I/O operation to complete. However, if it appears that the assumption was incorrect - then, the execution state of that "parallel universe" is simply discarded, and program execution is restarted back from said IF clause (as if speculative execution did not exist). But, since those prediction algorithms are pretty smart and polished, more often than not the guesses are right, which adds significant boost to execution performance for some software. Speculative execution is a feature that processors had for two decades now, which is also why any CPU that is still able to run these days is affected.

 

Now, while the two vulnerabilities are distinctly different, they share one thing in common – and that is, they exploit the cornerstone of computer security, and specifically the process isolation. Basically, the security of all operating systems and software is completely dependent on the native ability of CPUs to ensure complete process isolation in terms of them being able to access each other's memory. How exactly is such isolation achieved? Instead of having direct physical RAM access, all processes operate in virtual address spaces, which are mapped to physical RAM in the way that they do not overlap. These memory allocations are performed and controlled in hardware, in the so-called Memory Management Unit (MMU) of CPU.

 

At this point, you already know enough to understand Meltdown. This vulnerability is basically a bug in MMU logic, and is caused by skipping address checks during the speculative execution (rumors are, there's the source code comment saying this was done "not to break optimizations"). So, how can this vulnerability be exploited? Pretty easily, in fact. First, the malicious code should trick a processor into the speculative execution path, and from there, perform an unrestricted read of another process' memory. Simple as that. Now, you may rightfully wonder, wouldn't the results obtained from such a speculative execution be discarded completely, as soon as CPU finds out it "took a wrong turn"? You're absolutely correct, they are in fact discarded... with one exception – they will remain in the CPU cache, which is a completely dumb thing that just caches everything CPU accesses. And, while no process can read the content of the CPU cache directly, there's a technique of how you can "read" one implicitly by doing legitimate RAM reads within your process, and measuring the response times (anything stored in the CPU cache will obviously be served much faster). You may have already heard that browser vendors are currently busy releasing patches that makes JavaScript timers more "coarse" - now you know why (but more on this later).

 

As far as the impact goes, Meltdown is limited to Intel and ARM processors only, with AMD CPUs unaffected. But for Intel, Meltdown is extremely nasty, because it is so easy to exploit – one of our enthusiasts compiled the exploit literally over a morning coffee, and confirmed it works on every single computer he had access to (in his case, most are Linux-based). And possibilities Meltdown opens are truly terrifying, for example how about obtaining admin password as it is being typed in another process running on the same OS? Or accessing your precious bitcoin wallet? Of course, you'll say that the exploit must first be delivered to the attacked computer and executed there – which is fair, but here's the catch: JavaScript from some web site running in your browser will do just fine too, so the delivery part is the easiest for now. By the way, keep in mind that those 3rd party ads displayed on legitimate web sites often include JavaScript too – so it's really a good idea to install ad blocker now, if you haven't already! And for those using Chrome, enabling Site Isolation feature is also a good idea.

 

OK, so let's switch to Spectre next. This vulnerability is known to affect all modern CPUs, albeit to a different extent. It is not based on a bug per say, but rather on a design peculiarity of the execution path prediction logic, which is implemented by so-called Branch Prediction Unit (BPU). Essentially, what BPU does is accumulating statistics to estimate the probability of IF clause results. For example, if certain IF clause that compares some variable to zero returned FALSE 100 times in a row, you can predict with high probability that the clause will return FALSE when called for the 101st time, and speculatively move along the corresponding code execution branch even without having to load the actual variable. Makes perfect sense, right? However, the problem here is that while collecting this statistics, BPU does NOT distinguish between different processes for added "learning" effectiveness – which makes sense too, because computer programs share much in common (common algorithms, constructs implementation best practices and so on). And this is exactly what the exploit is based on: this peculiarity allows the malicious code to basically "train" BPU by running a construct that is identical to one in the attacked process hundreds of times, effectively enabling it to control speculative execution of the attacked process once it hits its own respective construct, making one dump "good stuff" into the CPU cache. Pretty awesome find, right?

 

But here comes the major difference between Meltdown and Spectre, which significantly complicates Spectre-based exploits implementation. While Meltdown can "scan" CPU cache directly (since the sought-after value was put there from within the scope of process running the Meltdown exploit), in case of Spectre it is the victim process itself that puts this value into the CPU cache. Thus, only the victim process itself is able to perform that timing-based CPU cache "scan". Luckily for hackers, we live in the API-first world, where every decent app has API you can call to make it do the things you need, again measuring how long the execution of each API call took. Although getting the actual value requires deep analysis of the specific application, so this approach is only worth pursuing with the open-source apps. But the "beauty" of Spectre is that apparently, there are many ways to make the victim process leak its data to the CPU cache through speculative execution in the way that allows the attacking process to "pick it up". Google engineers found and documented a few, but unfortunately many more are expected to exist. Who will find them first?

 

Of course, all of that only sounds easy at a conceptual level - while implementations with the real-world apps are extremely complex, and when I say "extremely" I really mean that. For example, Google engineers created a Spectre exploit POC that, running inside a KVM guest, can read host kernel memory at a rate of over 1500 bytes/second. However, before the attack can be performed, the exploit requires initialization that takes 30 minutes! So clearly, there's a lot of math involved there. But if Google engineers could do that, hackers will be able too – because looking at how advanced some of the ransomware we saw last year was, one might wonder if it was written by folks who Google could not offer the salary or the position they wanted. It's also worth mentioning here that a JavaScript-based POC also exists already, making the browser a viable attack vector for Spectre.

 

Now, the most important part – what do we do about those vulnerabilities? Well, it would appear that Intel and Google disclosed the vulnerability to all major vendors in advance, so by now most have already released patches. By the way, we really owe a big "thank you" to all those dev and QC folks who were working hard on patches while we were celebrating – just imagine the amount of work and testing required here, when changes are made to the holy grail of the operating system. Anyway, after reading the above, I hope you agree that vulnerabilities do not get more critical than these two, so be sure to install those patches ASAP. And, aside of most obvious stuff like your operating systems and hypervisors, be sure not to overlook any storage, network and other appliances – as they all run on some OS that too needs to be patched against these vulnerabilities. And don't forget your smartphones! By the way, here's one good community tracker for all security bulletins (Microsoft is not listed there, but they did push the corresponding emergency update to Windows Update back on January 3rd).

 

Having said that, there are a couple of important things you should keep in mind about those patches. First, they do come with a performance impact. Again, some folks will want you to think that the impact is negligible, but it's only true for applications with low I/O activity. While many enterprise apps will definitely take a big hit – at least, big enough to account for. For example, installing the patch resulted in almost 20% performance drop in the PostgreSQL benchmark. And then, there is this major cloud service that saw CPU usage double after installing the patch on one of its servers. This impact is caused due to the patch adding significant overhead to so-called syscalls, which is what computer programs must use for any interactions with the outside world.

 

Last but not least, do know that while those patches fully address Meltdown, they only address a few currently known attacks vector that Spectre enables. Most security specialists agree that Spectre vulnerability opens a whole slew of "opportunities" for hackers, and that the solid fix can only be delivered in CPU hardware. Which in turn probably means at least two years until first such processor appears – and then a few more years until you replace the last impacted CPU. But until that happens, it sounds like we should all be looking forward to many fun years of jumping on yet another critical patch against some newly discovered Spectre-based attack. Happy New Year! Chinese horoscope says 2018 will be the year of the Earth Dog - but my horoscope tells me it will be the year of the Air Gapped Backup.

 

Mal so wie der "Kollege" hier probiert?

https://community.hpe.com/t5/ProLiant-Servers-ML-DL-SL/Tape-Drive-recognized-as-CD-ROM/td-p/4837625

hier hat auch noch wer einen "Tipp":

http://www.sbsfaq.com/?p=2658

Kann auch nur Pro SSD stimmen. Die sind bei sowas wirklich der größte Turbo.

Aus eigener (NESTED) VM Erfahrung:

Vmware Workstation 12 Host mit I7 3770 und 16GB RAM. Virtueller ESXi 6 mit 9GB Ram und 2-3vcpu. Im ESXI dann 7 VM's mit je 1vcpu  und in Summe 8GB belegt. Bei den VMs muss man halt den Anforderungen entsprechend ram vergeben. Bei den VMs 1x dc, 3x server mit SQL/Oracle, 1 vm mit 2GB zum arbeiten. Virtuelles Homelab. 

der 2012er DC hat dann halt nur 700MB :-) .

Auf HDD: 45-60 Minuten nur bis der boot fertig ist.  Eventuell etwas weniger wenn ich jede VM einzeln für 5 minuten starten lasse.

Auf lokaler wie USB3.0 SSD: 5 Minuten, und alles ist durch.

Und auch das arbeiten ist deutlich besser. 1-2 VM von Platte mag gerade so gehen, aber alles andere ist nur unnötige Qual auch bei den etwas gestiegenen SSD Preisen.

@Sternenkind:

Wie zahni sagt, allgemein Storage und ggf. wenn Technik schon da ist das Interface bei einer Ausschreibung angeben.  ( dein Eternus braucht ja auch noch 2 10Gbit Switche)

Allgemein würde ich mich von Planungen/Überlegungen der Raid Level verabschieden. Moderne SAN bieten Autotiering/Data Progression, Compression und Deduplizierung der Daten "on-the-fly" an. Den Rest macht das SAN fast selbstständig.

Und ja, das geht auch mit über 100 Platten. Wie soll das sonst mit den Shelf Erweiterungen funktionieren? Es wird halt je nach Storage Anzahl x HDDs

Ich hatte z.b. eine alte MD3220i mit 10xR10 und 12xR5 durch eine Dell Scv2020 ersetzt. Gut, war All-Flash. Aber die teilt selbstständig in R-10 und R-5 auf. Alle Schreibzugriffe landen erst mal im schnelle R10. 1x täglich wird optimiert, weniger hot Daten landen auf dem R5. Je nach HDD Größe wird dann auchtomatisch ein R6 statt R5 angelegt.

Die größeren, wie jetzt die neuen SCv3000 bzw SCV5000 bieten dann auch Deduplizerung und Komprimierung an. laut Datenblatt sogar "4:1  All-Flash Storage Efficiency Guarantee". Gut, Marketing.

Ein Vergleich:  https://www.evaluatorgroup.com/document/entry-level-san-interactive-matrix/     einfach mit wegwerfmail mal registrieren. Ob für 80TB noch entry passt ist die andere Frage.

Zum besseren Verständnis wie so ein modernes SAN das aufteilt... 

Da finde ich die Doku von Dell recht "verständlich" für jemanden der sich nicht täglich damit befasst:

Understanding RAID with Dell SC Series Storage

http://en.community.dell.com/techcenter/extras/m/white_papers/20442059   

Lässt sich so auch auf andere Storage übertragen.

Ich kann da immer https://windirstat.net/ empfehlen. letztens war es ein Veeam Backup bzw. logs, die versteckt waren. Oder es war mal bei einem Desktop die SSD voll und da brauchte es ein Partition Tool, das die MFT des NTFS Laufwerks defragmentieren bzw. schrinken kann. 

@Binio: Wieviele Clients sind denn in der Domäne? 

Da hier ja mehrere Grundregeln (Exchange auf DC, nur 1 DC, kein Backup...) verletzt wurden, ist das eh verfahren. 

Es ist ja nicht nur der Exchange zerschossen, auch das AD. 

Falls eine Reparaturinstallation ( auf Kopie der Platte!) kein Erfolg verspricht, muss man hier wohl eh einen Cut machen.

Neues AD aufbauen. Neue Exchange Installation auf separatem Server. Recover des Exchange ist ggf. über Tools möglich, z.B. http://www.serversdatarecovery.com/exchange.html  Postfächer nach PST exportieren und dann wieder in das neue Exchange pumpen.

Einfach unterschieben wird ohne weiteres nicht klappen.. da ja das AD auch weg ist.

Alles in allem sehr aufwendig und zeitintensiv. 

"Dein Fehler" war wohl der Reboot und ggf. nicht vor der Arbeit zu fragen "gibt es einen funktionierenden Backup"? Wenn nein kein Garantie/Haftung für die Arbeit möglich. 

Jetzt kommt sicher die Argumentation "es lief ja vorher" was haben Sie gemacht? 

Ich würde beim Kunden offen die Situation kommunizieren und er muss entscheiden, welche Maßnahmen er bezahlen will. Mitarbeit deinerseits kostenfrei wird sicher erwartet werden. 

sind die Mails jetzt weg? oder kann ich sehen wer Mails geschickt hat, damit ich vielleicht hinschreiben und bitte die Mails nochmal zu schicken.

Die Frage kannst du dir doch eigentlich selbst beantworten. Der Pop3 connector macht ja nix anderes wie ein Outlook/Thunderbird, schaut ins Postfach z.b. bei GMX oder 1und1 und lädt diese runter.

ergo > über einen sicher möglichen Webzugang in die Postfächer schauen. 

Je nach Konfiguration /Typ des Pop3 connectors kann man einstellen, ob Mails online bleiben.

Beim SBS Default Pop3 Connector wohl nur an oder aus.

http://dnn.mssbsfaq.de/SBS2003/Exchange2003/Internetanbindung/POPConnectorMailsaufdemServernichtl%C3%B6schen/tabid/708/Default.aspx

Man kann das ja auch mal von der hypervisor Sicht sehen. Bin zwar bei VMware zuhause, aber einiges ist ja vergleichbar.

Stichwort overprovisioning.

Wieviele vcpu haben denn alle VMs zusammen?

Wieviel RAM außer den 32gb sind denn noch von den 64gb vergeben?

Eventuell der vm mal nur 24GB RAM, 16 Gb dem SQL geben. Die Anwendung selbst braucht ja auch was. Und dann vielleicht mal nur 4vcpu.

Ein 4 Disk raid-10 ist auch nicht gerade ein garant für Performance. Da kann eine einzelne ssd schon mehr bringen.

Bei 1500 Clients würde ich nicht mehr mit einer interen CA und Root Zertifikaten von internen CA rum werkeln. Das macht vielleicht ein Krauter wie ich  :)  mit 20 Clients, der die Domain noch mit einem Stammhaus teilen muss. ( und bisher nie die Zeit hatte, sich mit Spilt DNS zu beschäftigen). Bin ja auch nur 10-20% der Zeit Admin.

Ebenso  als Tip würde ich den Mail/Webserver mal über ssllabs.com testen. Da schein noch einiges "offen" zu sein in Sachen SSL. ISS Crypto ist da eigentlich sehr einfach hilfreich. Man muss nur schauen, was der Gerätepark so halt noch braucht.

Gibt sogar Skripte, die das dann in einen virenscanner schieben: https://www.frankysweb.de/server-2016-windows-defender-deinstallieren-anpassen/ ;)

Ok, war auch meine eigentlich "Quelle". Aber nachdem letztens NilsK über meinem "Franky'sWeb" link gemosert hatte, dachte ich mir mal, verlinke ich "uverfänglich".  :)

Gibt sogar Scripte für, die relevante Verzeichnisse "sammeln".

https://gallery.technet.microsoft.com/office/Generate-Antivirus-f1a9a59e

Na die einfachste Lösung wäre doch der integrierte Ressourcenmanager vom Windows Server?

https://www.frankysweb.de/exchange-2010-partitionfestplatte-der-datenbank-vollgelaufen-was-tun/

geht hier zwar erstmal um eine vollgelaufene Exchange Partiton... aber der Ansatz unter Absatz "Und was kann ich machen damit das nicht wieder passiert?"  ist ja der gleiche.

Da kann ich nur das out of office tool von Andy Sichel empfehlen:

http://asichel.de/downloads/out-of-office-tool

Ob das gewollt / und oder erlaubt ist würde ich mit GF und DSB absprechen.

Aber damit siehst du ja nicht in die Mailbox. Einzig Weiterleitungen wären problematisch.

Da ich auch ne kleine Umgebung mit 15 User und Exchange 2013 verwalte: 

Ja, von den 16GB sind auch nur 13,3GB belegt. Und da läuft noch der Symantec Mail Security mit auf dem Server 2012 + Mailstore.

Was hilft, genug vCPU. Bei mir sind es unter ESXi 6.0 4 vcpu.

Host hat "nur" 128GB, dafür 2x E5-2440v4.

Storage bei mir aber eine SAN mit All-Flash. 

Und da sehe ich beim TO den Knackpunkt. Auch mit 4GB Cache vom Raid-Controller wuppt ein 10x2TB Nearline SAS Raid nicht gerade. Und da kommt es auch noch auf den Raid-Level an.

War soviel Platz nötig oder war kein Geld für zumindest richtige 10K SAS Platten da? Die gibts ja auch schon relativ günstig mit viel Platz.

Viel Ram hilft hier halt nur begrenzt. I/O sind nur durch mehr I/O's zu ersetzen.

Kann ich so pauschal nicht unterschreiben. :)

 

PS: Zum Thema das SAN und die NAS: http://www.mcseboard...g/#entry1320799  :D

Hmmm... Siehe anderen Link weiter oben. ;)

 

 

Und ich "glaube", MS ist es egal, wie du mit deinem AD umgehst. Warum sollten die an der Stelle ein Supportstatement dieser Art abgeben?

 

Bye

Norbert

Ok, gebe zu, war zu faul da immer ein Quote zu machen.  :D

Den Unterschied einer SAN und NAS ist mir schon hinreiched bewusst. Je nach Wissen des Fragenden ist das manchmal schwierig rüber zu bringen. Daher sehr vereinfacht dargestellt.

Zum Thema Virtual DC. Da wäre ich doch jetzt nicht der erste mit dem gefährlichen Halbwissen. :cool: