Im Datenbank Bereich ist es ähnlich, gut, bei ORACLE mit großen komplexen Abfragen beginnt die DB auch jede Menge CPUs auszulasten, aber dennoch gilt, der Skaliereffekt tritt erst bei vielen Concurrent Usern auf.
Was letztlich von dem internen Oracle Query Optimizer abhängt, was für eine Art von Abfrage durchgeführt werden soll: über Table Index oder Full Table Scan. Das DB-Backend nutzt die konfigurierten Hardware-Ressourcen automatisch.
Java und J2EE ist auch sehr interessant. Ein großer Java Application Server kann bei Vorhandensein einiger CPUs schon sehr gut skalieren, bzw. jede Menge CPUs einbeziehen.
Je nachdem, wie viele Anwendungen (z.B. EJB) im Application Server (Middleware) deployed wurden, wieviele Anfragen von Clients unterstützt werden sollen, wie viele DB Connections in DB Pool(s) konfiguriert sind usw. Das sind alles sehr umfassende und keine so triviale Konfigurationen mehr.
Also für den Klassiker Apache+Mysql+PHP ist die Fire meiner Meinung nach die absolut verkehrte Maschine. Ausser du musst einige tausend User gleichzeit bedienen... Ein dicker Oracle Server + J2EE Application Server + SAP R/3 Server + usw. treffen eher den Anwendungsbereich der SF6800.
Jo. So is' es. Das hängt auch von der Anzahl der User ab, von den Software-Voraussetzungen und von den Anforderungen des Kunden.
Das Letztere wird wohl dann der Fall sein, wobei ich anfangs trotzdem aus Kostengründen erstmal lieber MySQL einsetzen werde. Apache inkl. Perl wird drauf laufen. Die Anwendung an der wir hier schreiben, ist tatsächlich ein ziemlich dicker Brocken.
Warum nutzt ihr nicht die PostgreSQL Datenbank, die direkt von Solaris 10 mitgeliefert wird? (Meik hat das schon vorgeschlagen.)
Wie sieht es mit Planungen zu Failover-Konfigurationen, Service-Level, Performance-Level bei Euch aus? ...
Aber das ist alles noch Zukunftsmusik. Wenns nämlich mit der SF nicht klappt, muß eine große x86 Maschine ran. Oder sogar zwei davon, wegen der Clusterei.
Allerdings: das sind alles Themen über die man sich den Kopf zerbrechen sollte und die nicht länger ohne Auswirkung bei Nicht-Beachtung/-Einhaltung bleiben.
...Eine Backplane austauschen zu müssen, weil ein Techniker ein Teil aus versehen falsch eingebaut hat, ist ärgerlich, und wenn da Instanzen drauf laufen, die wichtig sind, für den Kunden auch teuer. ...
Eine Komponente FALSCH einzubauen ist bei solchen Maschin'chen in den meisten Fällen heute schon nicht mehr so einfach möglich. Da muss man mitunter schon brachiale Gewalt walten lassen. Ist also auf gut deutsch
fast Idioten-sicher.
Was die Instanzen (wahrscheinlich Logical Domains) betrifft, ist das bedeutungslos. Diese Instanzen sehen nur "virtuelle" Hardware. Die "realen" Ressourcen werden verborgen und bleiben so jederzeit im laufenden Betrieb austauschbar und
rekonfigurierbar.
