metux

Klar, trifft aber auf die da genannte Backup-Software genauso zu - die eigentliche Backuplösung muß man ja ohnehin im konkreten Falle selbst entwickeln. Insofern halte ich das schon für eine gute Option, das Backup auf VM-Layer zu lösen. Möglicherweise bietet VMWare da sogar eine Möglichkeit, VM-Snapshots mit den Storage-Snapshots zu konsistent zu koordinieren (sollte evtl. via barriers möglich sein) - dann bräuchte man nach einem fail die VM's nichtmal neu booten.

Unglückliche Formulierung. Vielleicht besser: "Evaluation von Side-By-Side Deployment des OWS zur Ausfall- und Kostenreduktion bei Migrationen und Updates". Warum HW-Migration (bitte was ist x64 ?) und ein OS-Wechsel notwendig ? Außerdem: Dein Projekt ist ja wohl nach der Migration auf OWS angesiedelt, also würde ich das allenfalls nur ganz kurz erwähnen. Die aktuelle Formulierung ist da etwas verwirrend. Wenn ich das richtig verstanden hab, gehts ja überhaupt nicht um die Migration, sondern Evaluation und Einsatz von side-by-side-deployment. Das Projekt als solches würde ich in zwei große Teile gliedern: a) technisch: ist der Mechanismus für Euch überhaupt einsetzbar, welche Einsatzmöglichkeiten gibt es ? Wie sollten die Prozesse aussehen ? kaufmännisch: Vergleich des aktuellen vs. neu vorgeschlagenen Prozesses und entsprechender Aufwände, mittel- und langfristig.

Hi, was mir als altgedienten IT-Berater sofort auffällt: * das liest sich nach einer klassischen ERP-Aufgabenstellung. Sowas würd ich nicht von Grund auf neu entwickeln, sondern etwas existierendes (zB. OpenERP, vTiger, ...) nehmen und ggf. entsprechend customizen * wie sehen die aktuellen Workflows aus ? wie sollen sie zukünftig aussehen ? * Punkt 6.1 ist mir völlig unklar: warum nur Deployment der Exportfunktion - warum nur der Export (ist das ein dediziertes Modul?), und was ist mit dem Rest ? * warum ist Deployment kein eigenständiger Punkt ? Was ist mit der Migration der alt-Daten ?

Richtig. Es gibt eine Menge Faktoren, die hier noch garnicht bekannt sind. Wichtigste Frage: kopierst Du filesystem-basiert oder direkt blockorientiert ? Das entscheided schonmal über zusätzliche seek-times (die man aber ohne vorherige Analyse des Filesystems nichtmal erahnen kann). Zudem ist noch wichtig, ob der Host zu dem Zeitpunkt ansonsten im Leerlauf oder noch mit anderen Dingen beschäftigt ist, usw, usw. De facto kann man nur innerhalb eines vergleichbaren Lastszenarios messen (blocktrace/blockreplay können da helfen). Wenn das eine Schul-/Prüfungsaufgabe ist, würde ich die theoretische Bandbreite ausrechnen, und dann aber klar darstellen, daß diese rein theoretisch ist, und anschließend einige wichtige Performance-bremsende Faktore nennen, mit der Schlußfolgerung, daß man - ohne Messung im konkreten System - keine belastbare Aussage treffen kann.

Warum unterschiedliche Prioritäten ?

Nun, psexec scheint - laut manpage - sowas ähnliches wie rexec zu sein. Die interessante Frage ist, über welches Protokoll das läuft, und wie's da mit der Sicherheit aussieht. Ich würde dem jedenfalls nicht vertrauen, sondern lieber etwas erprobtes wie ssh nehmen, womit man dann auch plattformunabhängig ist.

Vielleicht auch mal Redmine genauer anschauen.

Kurze Zwischenfrage: warum nicht einfach das SAN snaphots machen lassen ?

Nunja, das Thema Groupware taucht hier ja öfters auf. Und da ist in der Gesamtbetrachtung - wenns um professionellen Einsatz, vorallem mit Cluster und HA geht - der ZCS ziemlich konkurrenzlos. In anderen Bereichen gibts da ähnliche Fälle, würde ich zB. nach einem VCS gefragt wäre die Standardantwort: git.

Vielleicht lohnt sich an der Stelle auch mal ein Blick auf sane. Da ist auch ein scanner-server dabei.

By the way: werden da eigentlich auch moderne VCS'e, zB. git, behandelt ?

Warum mountest du nicht einfach direkt den server ? Oder läßt ihn automatisch (per hook, etc) aus dem VCS synchronisieren ?

Warum das ?

Redmine ? OTRS ?

Warum nicht einfach per rsync aufs NAS schieben und entweder a) rsync die überschriebenen Files wegschieben lassen oder (man 1 rsync) oder das NAS snapshots von den backup-volumes machen lassen ? Oder alternativ: die lokalen HD's 1:1 auf gleich große iscsi-volumes spiegeln und hinterher das NAS snapshots machen lassen.

Ich könnte da noch Hosted-Zimbra mit RZ in der Schweiz vorschlagen ... ;-)

Installier auf den Kisten 'nen sshd, dann kannst Du den Rest relativ easy scripten.

Vielleicht möchte er ja eigentlich eine hochverfügbare Groupware-Lösung, und der Exchange steht da zufällig einfach nur dumm rum ?

Warum so einen Aufwand wegen ein paar Platten ? Einfach aufmachen und kurz abspülen - dann ist das Medium nur noch Müll.

vielleicht openldap + gosa (als bequemes frontend) ?

Hast Du Dir schonmal Zimbra angeschaut ?

Auch da ist es ganz einfach angreifbar.

Garnicht. Dafür bekommst Du aber eine hochverfügbare Groupware-Lösung. (ja, zur HA gehört natürlich noch etwas mehr dazu, als einfach nur eine ZCS-Multiserver Installation)

Dokumentiere doch einfach mal die Aufwände die Du mit der Sauerei verbrennst. Und dann machst Du mal einen Vorschlag für saubere Workflows.

Da sollte sich mal der PjM drum kümmern und Anranzer verteilen. Oder man organisiert seine Arbeitsabläufe so, daß man nicht ständig aufeinander angewiesen ist. Ja, das kenn ich von meinen Jungs auch. Hab ich ihnen mittlerweile abgewöhnt. Als erstes (nach der Migration auf git) hab ich topic-branches eingeführt. Was nicht sauber baut+funktioniert und gewisse QM-requirements erfüllt, kommt einfach nicht in die Mainline, und das Ticket geht wieder zurück. Das Spiel muß man erstmal eine Weile durchziehen, dann lernen die schon, was sie falsch gemacht haben ;-o Das einzufordern ist ebenso Aufgabe des Maintainers bzw. HoD. Gleiche policy: was die Mindestanforderungen nicht erfüllt, kommt nicht in die Mainline, Ticket zurück. Man spiele dieses Spiel so lang bis die Leute genervt genug sind, daß sie anfangen ihre Arbeit ordentlich zu machen.