-
Feedback zu Systemkonfiguration iSeries
Hallo, mir geht es um die Bewertung einer exemplarischen Systemkonfiguration für unsere neue iSeries zum Jahresende sowie eure Erfahrungen mit den Technologien bzw. welche Bedenken ihr dazu hättet.
Ziel: HA-System 24x7 mit DevLPAR für Testumgebung Entwicklung mit Zero-Datenverlust sowie vermeiden des täglichen befördern des Sicherungsbands vom RZ in den Tresor sowie dem ca. 1 stündigen Sicherungsfenster in dem alle SBS down (SAVLIB) sind während der Nacht(schicht), da wir zukünftig mit webshop u. anderen schnittstellen nach außen verfügbar sein müssen.
Angeboten wurden eine Produktiv u. Backupmaschine mit externen Storage All-Flash (IBM Storwize V5030E) mit Raid 6.
- HA-Tool entweder Bus4i, Mimix, iTera - wie bewertet ihr diese? iTera ist bislang im Einsatz aber unvollständig konfiguriert, sodass ein Umstieg nicht weh täte
- Auf dem Prod-System wäre die Entwicklungs-LPAR, welche per nächtlichem Abgleich die aktuellen Produktivdaten erhalten soll. Unterm Tag soll unter Umständen auch aktualisiert werden können
- Das gespiegelte Backupsystem soll gleichzeitig mittels Flashcopy und BRMS gesichert werden über die Tape Library unter der Woche, sodass nur einmal die Woche die Bänder in Tresor gelegt werden müssen. Falls unterm Tag etwas restored werden müsste (menschliches Versagen) so müssen die Bänder nicht lang geholt werden u. BRMS sagt einem welches Band notwendig ist.
Externer Storage ist momentan mit SSD günstiger angeboten wie interner Storage.
Wie sind eure Erfahrungen mit All-Flash Systemen? Würdest ihr 8 SSDs im Raid 6 gegenüber 30 kleinen 280 GB HDDs dem Vorzug geben? Gefühlsmäßig werden IOPS bei den SSDs trotzdem höher sein.
Momentan haben wir in der 4 Jahre alten Maschine 64 GB RAM - diesen würden wir auf 256 GB Ram anheben - bei welchen Operationen wäre das v.a. notwendig?
Im PC Bereich machen wir unter der Woche Backup-To-Disk, wie würde das bei der i aussehen?
Freue mich auf eure Resonanz!
-
Hallo
ich habe vor 5 Jahren von Power7 mit 6HDDs auf POwer7+ mit 4 SSDs (gespiegelt !! )
umgestellt, mit dem Ergebnis, dass zB Query bis zu 100 !! mal schneller laufen .
Generell läuft natürlich alles schneller (auch dem Prozessor geschuldet).
Die alte POwer7 beherbergt jetzt (nur) die Replikation (OMS400)
Auf unserer aktuellen 7+ Maschine laufen immer über 200 Interaktive Jobs.
Ein auf beiden Systemen ausführtes Query über mehr als 15.000.000 Sâtzen
lief eben auf dem alten 40 Sekunden, auf dem neuen 1 ! Sekunde !!
Gruss
Jotho
-
200 interaktive Jobs sind ja fast nichts.
Und 15.000.000 Sätze unter 1 Sekunde ist bestimmt Indexoptimiert;-).
-
Zitat von Gutmann
Freue mich auf eure Resonanz!
Wir haben mit BUS4i gute Erfahrungen gemacht. Du brauchst aber dann kein FlashCopy mehr, sondern PROD und BACK Partitionen haben jeweils eigenen Storage. Statt physischem Tape wäre auch eine VTL möglich. Geht noch schneller.
8 SSDs sind weit aus flotter als 30 kleine HDDs - kann ich nur empfehlen.
mehr RAM ist immer gut, gerade, wenn viel gelesen wird. Der RAM dient dann schön als Puffer (wer hat noch mal "in memory" erfunden? ;-)
Backup-to-disk ist immer nett, sofern die Disk woanders ist.
-
"In memory"-DB hat wirklich nichts mit Cache und Paging zu tun.
Wenn es danach geht brauche ich eben auch für eine Firebird-DB nur genügend Hauptspeicher um letztlich "In memory" zu arbeiten.
Der wirkliche Unterschied besteht in der Objektorientierung vs. relationaler Daten. Das macht die Verarbeitung dann wirklich schnell.
-
ich hab immer indexe, der deckt aber nur einen Teil meines Querys ab.
Laut Anzeige (Statuslinie) sind nach gefühler halben Sekunde sofort über 5 Mil. Sâtze verarbeitet,
nach 1 Sekunde 11 Mil. ....
Im übrigen gilt der Index dann wohl auch für die andere Maschine !
Gruss
-
Das ist korrekt. Entscheidend für solche Zahlen ist i.W. der Hauptspeicher.
Ich selber habe als Singleuser keine Effekte zwischen SDD und HDD gemessen.
Nur der Gesamteffekt für die Maschine in Summe macht diesen Effekt letztlich aus.
Wenn dann allerding auch noch die CPU um Faktoren schneller ist, sinkt der SDD-Anteil nicht unerheblich.
-
Zitat von Fuerchau
"In memory"-DB hat wirklich nichts mit Cache und Paging zu tun.
Wenn es danach geht brauche ich eben auch für eine Firebird-DB nur genügend Hauptspeicher um letztlich "In memory" zu arbeiten.
Der wirkliche Unterschied besteht in der Objektorientierung vs. relationaler Daten. Das macht die Verarbeitung dann wirklich schnell.
Da kann man schön Stunden lang drüber diskutieren - aber in Zukunft (und beim Hauptakteur SAP) wird "in Memory" vermutlich hauptsächlich was mit Geld zu tun haben.
-
Da gebe ich dir vollkomen Recht;-).
Similar Threads
-
By LordCinimod in forum NEWSboard Programmierung
Antworten: 45
Letzter Beitrag: 13-01-16, 08:41
-
By Heinz Molter in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 01-06-03, 16:59
-
By vogeste0 in forum NEWSboard SAP
Antworten: 4
Letzter Beitrag: 15-04-02, 08:56
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks