Hochverfügbarkeit...

[rewelrider 10]

@ Ramme:

 

danke-DAS schaut mal gut aus, auch weils nicht div zusätzliche Speichersysteme brauchen würde und wir sowieso HP Server verwenden-da kanns dann auch einer aus deren Liste sein, nebenbei sei erwähnt das ich mal als "Richtung" in Bezug auf den Preis eine Zahl habe: "20.000€" und ich denk das ist schon mal halbwegs "verünftiger" Betrag mit dem sich ein bisschen was machen lassen sollte

 

Danke für den Tipp...ich versuch einfach mal ein paar Möglichkeiten zu sammeln, dein Vorschlag ist sicher mehr als interessant...

 

lg

[PowerShellAdmin 169]

hm etwas OT,

aber wieso die Daten nicht in eine SQL DB geschrieben und das Frontend bleibt Access ?

SQL Cluster kann ja dann folgen... würde wohl "etwas" teurer werden *fg*

 

Grüße Admin

[Ramme 11]

@ Ramme:

 

"20.000€" und ich denk das ist schon mal halbwegs "verünftiger" Betrag mit dem sich ein bisschen was machen lassen sollte

 

lg

 

Na damit kannst einiges machen. Kommt natürlich darauf an, Welche Leistung am Server gefordert ist, und wie das Netzwerk strukturiert ist.

 

Gruß

 

JBC-service

[rewelrider 10]

@PowerShellAdmin

 

sicher gibts andere Möglichkeiten, es sei an dieser Stelle aber erwähnt das es sich hier um den Einsatz im med Bereich handelt, dies bedeutet das Änderungen an der Software quasi unmöglich sind.....in diesem Bereich ist alles nicht ganz so einfach wie anderswo....leider.....di

 

Auch sind im Bereich unserer Software (bei Hardware oder zusätzlicher Software schauts wieder anders aus) "Einzellösungen" nicht machbar da meine Firma großen Wert darauf liegt im Softwarebereich weltweit genau das gleiche in Bezug auf das Produkt, die Version usw einzusetzen. Auch das sollte hinterfragt werden-ist aber ebenfalls einfach mal so...ich bin "zu klein" um hier für einen Richtungswechsel zu sorgen.

 

Es gibt ein internes Papier das den Umstieg auf SQL kurz erwähnt....Zeitraum/Zeitpunkt aber "offen" und dieses Doc ist 4 Jahre alt. Auf Anfrage meinerseits wie es da ausschaut kam ein "auf unbestimmt verschoben"

 

Weiters ist das FrontEnd nicht Access sondern ebenfalls ein Eigenprodukt meiner Firma.

 

@Ramme

wir brauchen eigentlich Null Leistung. Die Mindestanforderung für unseren Server:

1GHZ CPU

1GB Arbeitsspeicher

5GB HDD Speicherplatz (wieso auch immer denn die DB hat im Extremfall 100MB, der komplette Installationsordner ist keinen GB groß)

 

lg

[rewelrider 10]

Sunny61 du magst recht haben das es bei anderen Anforderungen mit Access Probleme geben würde, ich denk aber das ein Produkt von den Verantwortlichen wohl auf Basis der Anforderungen gewählt wird und unsere Anforderungen sind nun mal sehr nieder...

 

Das jeder sagt Access wäre mies liegt nicht daran das unsere Lösung nicht funktioniert (ganz im Gegenteil) sondern man merkt allgemein das alle IT Verantwortlichen zusammenzucken wenn ich auf die "Welche DB" Frage mit Access antworte. Es herrscht große Ablehnung-obwohl man unsere Umsetzung nichtmal kennnt.

 

Und das man SQL auch gratis bekommen kann ist mir bekannt. Es sei aber erwähnt das du dann auch Leute brauchst die sich damit auskennen. Ein Access File vom defekten Server auf einen neuem kopieren kann jeder, SQL downloaden, installieren, unter Umständen einrichten, Fehler suchen usw ist schon wieder ganz was anderes...

[Dr.Melzer 191]

Das jeder sagt Access wäre mies liegt nicht daran das unsere Lösung nicht funktioniert (ganz im Gegenteil) sondern man merkt allgemein das alle IT Verantwortlichen zusammenzucken wenn ich auf die "Welche DB" Frage mit Access antworte. Es herrscht große Ablehnung-obwohl man unsere Umsetzung nichtmal kennnt.

 

Dann würde ich mir echt mal Gedanken darüber machen ob die nicht doch alle recht haben und ihr mit Access vielleicht auf das falsche Pferd gesetzt habt, egal wie "toll" eure Lösung aus eurer Sicht funktioniert...

 

Wenn ein Spediteur ein fahrzeug benötigt um Lasten zu transportieren sagt ihr ihm dass ihr eine tolle Lösung habt die super funktioniert. Dass er dann zusammenzuckt wenn ihr sagt dass eure Lösung auf der Basis von Pferdefuhrwerken basiert muss es dich nicht wundern... ;) :D

[zahni 558]

Access im Multiuser-Betrieb ist einfach schrecklich. Ein Admin ;)

[Sunny61 809]

Sunny61 du magst recht haben das es bei anderen Anforderungen mit Access Probleme geben würde, ich denk aber das ein Produkt von den Verantwortlichen wohl auf Basis der Anforderungen gewählt wird und unsere Anforderungen sind nun mal sehr nieder...

 

Sie waren niedrig. Mittlerweile wollt ihr ja Hochverfügbarkeit anbieten, das in Zusammenhang mit Access passt nicht.

 

Das jeder sagt Access wäre mies liegt nicht daran das unsere Lösung nicht funktioniert (ganz im Gegenteil) sondern man merkt allgemein das alle IT Verantwortlichen zusammenzucken wenn ich auf die "Welche DB" Frage mit Access antworte. Es herrscht große Ablehnung-obwohl man unsere Umsetzung nichtmal kennnt.

 

Ich habe nicht geschrieben Access ist mies, ich arbeite selbst sehr viel und intensiv mit Access. Eine MDB ist eine Textdatei mit einer GUI oben drauf. Mir wäre aber nicht wohl bei dem Gedanken, zu wissen meine medizinischen Daten liegen in einer MDB. Das Wort Sicherheit darf hier nicht fallen, denn eine Textdatei ist nicht sicher. Und egal wie ihr die MDB "absichert", sie ist in kürzester Zeit entsichert.

 

Die IT Verwantwortlichen verdrehen bei Access die Augen, weil man einfach so viel damit machen kann. Und niemand kann das richtig kontrollieren.

 

Und das man SQL auch gratis bekommen kann ist mir bekannt. Es sei aber erwähnt das du dann auch Leute brauchst die sich damit auskennen. Ein Access File vom defekten Server auf einen neuem kopieren kann jeder, SQL downloaden, installieren, unter Umständen einrichten, Fehler suchen usw ist schon wieder ganz was anderes...

 

Willst Du damit sagen, eure Leute können nur ein Access File kopieren? Wie macht euer Programm zur Zeit ein Backup der laufenden MDB? Ein SQL Server, egal ob Express oder nicht, bringt diese Technik mit, Du brauchst sie nur zu nutzen. Natürlich kannst Du das im laufenden Betrieb machen.

 

Nochmal, Access bzw. eine MDB ist gut für diverse Aufgaben. Aber die Worte Access, MDB, ACCDB und Hochverfügbarkeit in einen Topf zu werfen ist falsch. Noch dazu im medizinischen Bereich. Und dabei ist es egal ob das alle machen, deshalb wird es nicht richtiger.

[Sunny61 809]

Access im Multiuser-Betrieb ist einfach schrecklich. Ein Admin ;)

 

Nein, ganz und gar nicht. Man muss es nur richtig machen. ;) Glaub mir, ich kenn das sehr gut.

[Dobi 11]

@rewelrider

Ich arbeite in einem Krankenhausverbund, und ja es gibt einige Access "Entwicklungen" in unserem Umfeld, aber die wirklich wichtigen (wie KIS, PDMS, Monitoring - Systeme usw., die eine wirklich hohe Verfügbarkeit haben müssen) laufen nicht in Verbindung mit Access.

Also diese Hochverfügbarkeit würde ich wirklich mal hinterfragen, weil als Kunde kann ich das von einer Access Applikation nicht verlangen und auch meinen Kunden nicht anbieten.

[Ramme 11]

@PowerShellAdmin

 

@Ramme

wir brauchen eigentlich Null Leistung. Die Mindestanforderung für unseren Server:

1GHZ CPU

1GB Arbeitsspeicher

5GB HDD Speicherplatz (wieso auch immer denn die DB hat im Extremfall 100MB, der komplette Installationsordner ist keinen GB groß)

 

lg

 

Hallo,

 

das sind mal niedrige Anforderungen :). Für ca. 5000€ netto kann man für solche Anforderungen zertifizierte Server, entsprechender Garantieleistung und die Software bekommen.

 

Gruß

 

JBC-service

[Lian 2.449]

Hallo,

 

aktuell reden wir nicht über erhöhte Verfügbarkeit oder echte Hochverfügbarkeit, sondern bestenfalls über Schaffung von Redundanzen, Verbesserung der Recoveryzeiten etc.

 

Das bitte nicht als Kritik auffassen: Wir sollten allerdings m.E. nicht Begrifflichkeiten verwenden, die nur zur allgemeinen Verwirrung beitragen.

 

Wenn es tatsächlich um Hochverfügbarkeit einer Datenbank geht, reden wir im Windows Umfeld von einem Windows Server Failover Cluster der die Rolle MS SQL Server bereithält.

Dann ergibt es auch einen Sinn über SLAs und Verfügbarkeiten zu sprechen.

[RRohde 10]

Hallo,

 

aktuell reden wir nicht über erhöhte Verfügbarkeit oder echte Hochverfügbarkeit, sondern bestenfalls über Schaffung von Redundanzen, Verbesserung der Recoveryzeiten etc.

 

Das bitte nicht als Kritik auffassen: Wir sollten allerdings m.E. nicht Begrifflichkeiten verwenden, die nur zur allgemeinen Verwirrung beitragen.

 

Wenn es tatsächlich um Hochverfügbarkeit einer Datenbank geht, reden wir im Windows Umfeld von einem Windows Server Failover Cluster der die Rolle MS SQL Server bereithält.

Dann ergibt es auch einen Sinn über SLAs und Verfügbarkeiten zu sprechen.

 

Hallo an alle,

 

dem ersten Teil stimme ich voll zu - bisher wurde kaum ein Ansatz diskutiert, der die Eigenschaft "hochverfügbar" für sich in Anspruch nehmen dürfte. Auch bei Clustelösungen haben wir so unsere "Bauchschmerzen" (es gibt dort per se zunächst immer einen Single Point of Failure, der separat behandelt werden muss -> Kosten!)

 

Nichts destro Trotz gibt es tatsächlich hochverfügbare Lösungen für diese Probleme (bis zu fehlertoleranten Lösungen). Bei dem Ansatz von Marathon Technologies wird der komplette Server "gespiegelt" (wie z.B. ein Festplattenraid - nur eben mit dem kompletten Server). Das passiert vollkommen unabhängig von der Applikation (also kein "clusteraware" notwendig ... auch Access funktioniert ;-)). Fallen in diesem System Komponenten aus, läuft der Server ohne jegliche Unterbrechung oder Umschaltung weiter - das funktioniert sogar bei Ausfall eines kompletten Hosts. Diese Lösung erreicht eine Systemverfügbarkeit von 99,999% (zum Vergleich: ein Cluster kommt gerade mal auf 99,9%.)

 

Schreibt mich einfach an - ich bin gern bereit, detailliert Auskunft zu geben (unser Kerngeschäft ist seit mehr als 10 Jahren das Gebiet der hochverfügbaren Server).

 

Gruss aus Berlin

Reiner

[zahni 558]

@RRohde,

 

Du hast beim Erstellen Deines Accounts auch die Regel Nr. 4 https://www.mcseboard.de/rules.php#nr4 akzeptiert.

 

Warum hältst Du Dich nicht daran ?

 

Wir haben in den Thread ausführlich erläutert, das Hochverfügbarkeit ein ganzheitlicher Ansatz ist und nicht mit irgendeinem Produkt einfach so erledigt werden kann. Beim TO ist die Access DB ein KO-Kriterium, bei dem Dein Produkt auch nicht weiterhilft.

 

PS: Wen es interessiert: http://www.xing.com/profile/Reiner_Rohde

[RRohde 10]

@RRohde,

 

Du hast beim Erstellen Deines Accounts auch die Regel Nr. 4 https://www.mcseboard.de/rules.php#nr4 akzeptiert.

 

Warum hältst Du Dich nicht daran ?

 

Wir haben in den Thread ausführlich erläutert, das Hochverfügbarkeit ein ganzheitlicher Ansatz ist und nicht mit irgendeinem Produkt einfach so erledigt werden kann. Beim TO ist die Access DB ein KO-Kriterium, bei dem Dein Produkt auch nicht weiterhilft.

 

PS: Wen es interessiert: Reiner Rohde - Geschäftsführer - Informationstechnolog ... | XING

 

 

Hallo "Expert Member",

 

1. Ich hatte an keiner Stelle die Absicht in irgendeiner Form Werbung zu machen. Selbstverständlich ist Hochverfügbarkeit ein ganzheitlicher Ansatz - allerdings geht es nicht ganz ohne entsprechende technische Unterstützung - und in diesem Feld gibt es wiederum extrem wenige Hersteller (um genau zu sein: 2 (zwei) - Marathon Technologies und STRATUS). Ich bin gern bereit, die Unterschiede zu erklären.

 

2. Wie kommst Du darauf, dass Marathon everRun MX (das wäre z.B. ein passendes "Produkt") ausgeschlossen ist, wenn ACCESS DB das ko-Kriterium ist? Für mich ein deutliches Zeichen, dass Du Dich in diesen Lösungen nicht besonders gut auskennst: Bei everRun MX wird der komplette Server (nochmal: unabhängig von der jeweilig installierten Applikation) im sogenannten lockstep-Verfahren auf zwei Hardware-Tuples parallel betrieben. Solange in diesem Verbund noch wenigstens eine Komponente exisitiert, die zur Funktion benötigt wird (einer von zwei Prozessoren, einer von zwei RAM-Bereichen, eine von zwei NIC's, eine von zwei Festplatten, etc.) - solange funktioniert der Server (W2K3 oder W2K8) und mit ihm die ACCESS DB z.B. ohne jegliche Unterbrechung, ohne Datenverlust und ohne Transaktionsverlust.

 

3. Danke für den link zum meinem Profil (der war übrigens von Dir, ich hätte das nicht gepostet wegen genau der Regel Nr. 4., im Übrigen steht in meinem Profil auch unsere Webseite, auf der findet Ihr einen guten Überblick über Hochverfügbarkeitslösungen.)

 

Für alle, die sich tatsächlich für professionelle Ansätze auf dem Gebiet hochverfügbarer Server interessieren, stehe ich gern zur Verfügung.

 

Beste Grüße

Reiner Rohde