13 Replies Latest reply on Aug 1, 2012 4:47 AM by Klaus Salger

    Trennung Work / Install

    Klaus Salger Expert
      Hi all,

      standardmäßig werden ja Paketkopien in Work und Install gehalten und so habe ich das bisher auch immer gelassen.
      Es gibt aber auch die Möglichkeit, auf Repository-Ebene zu konfigurieren, dass Pakete ausschließlich im Install-Verzeichnis liegen sollen, d.h. die Work-Kopie der Pakete entfällt.
      Das macht man traditionell wenn man an einen Standort distribuieren muss, der keinen eigenen Distributionsdienst hat um zu vermeiden, dass die Work-Install-Distribution über einen WAN-Link erfolgt und die Pakete damit mehrmals über den WAN-Link gehen.

      In der guten alten NI5-Zeit hatte man den Nachteil, dass man auf dem Repository-Master nicht mehr zwischen "in Arbeit" und "freigegeben" unterscheiden konnte, d.h. wenn der Repository-Master direkt für die Verteilung auf Clients verwendet wurde, dann hatte man evtl. konkurierende Zugriffe von Admins / Paketierern, Distributionsdiensten und Clients.

      Seit enteo V6 mit Einführung der Revisionierung sollte man das Problem nicht mehr haben.
      Der aktuelle Stand ist ja bereits per "Vorbereitung der Distribution" von den Installationskopien in den Rev-Verzeichnissen getrennt.
      Damit wäre die Trennung von Work und Install eigentlich überflüssig.

      Wenn man nicht mehr trennen müsste, dann würde man sich nicht nur eine Kopie der Pakete und damit eine ganze Menge Speicherplatz in den Depots sparen, sondern man hätte erheblich weniger lokalen Distributionstraffic und weniger distributionsbedingte Verzögerungen. Von Work nach Install kopiert werden müsste dann nur noch das Repository-File (.nid).

      So jetzt (endlich) zu meinen Fragen:
      1. Sieht jemand etwas, was ich nicht sehe, nämlich Probleme damit auf das Work-Verzeichnis zu verzichten? Und welche wären das?
      2. Verwendet jemand die Möglichkeit die Pakete nur im Install-Verzeichnis zu halten? Wie sehen die Erfahrungen aus?

      Danke
        Klaus
        • 1. Re: Trennung Work / Install
          NicoS1 Master
          Hallo Klaus,

          was ein Zufall... mit diesem Thema beschäftige ich mich auch zur Zeit. Ich muß aber ehrlich gestehen, ich habe aktuell die Möglichkeit noch nicht gefunden, auf den Depots nur "Install" vorzuhalten und nicht das Work Verzeichnis. Wäre nett, wenn du mir da auf die Sprünge helfen könntest.

          Zu den "Problemen". Ich hab mir auch den Kopf zerbrochen, was hier ein Showstopper wäre um das umzusetzen. Mir fallen im Prinzip nur 2 Stück ein:

          1. Die Leitungsauslastung wäre aus meiner Sicht größer, da bei der Work <=> Work Distribution gepackte Dateien ausgetauscht werden. Bei einer Install <=> Install Distribution müssten es ja theoretisch entpackte Dateien sein. Dementsprechen größer, und mehr Leitungsauslastung.

          2. Ist die Gefahr von defekten Installationssourcen höher. Speziell bei Paketen mit sehr großen, oder vielen kleinen Dateien.

          Gruß
          • 2. Re: Trennung Work / Install
            Michi Expert
            Hi,

            ich hab mich zu v6 Zeiten auch mal damit beschäftigt.
            Hab das nur in meiner Testumgebung ausprobieren können. Probleme sind mir dabei jetzt keine aufgefallen. Allerdings hab ich trotzdem immer so ein paar Bedenken, damit produktiv zu gehen.

            Auch hat sich das Platzthma ja weitestgehend erledigt, da ja im Install mit Hardlinks gearbeitet wird. Die paar KB pro Link sollten absolut verschmerzbar sein.

            Allerdings müssen die Links auch angelegt werden und die Distributionsläufe abgewartet werden, was widerum für ein Verzeichnis sprechen würde.

            Ich persönlich werde auch bei Work/Install bleiben, da es ziemlich sicher nicht supportet ist. Die Möglichkeit mit nur einem Verzeichnis hat man ja auch nur beim anlegen weiterer Repositories. Gefallen tuts mir aber ehrlich gesagt auch nicht  ;-)

            Gruß
            Michi
            • 3. Re: Trennung Work / Install
              Klaus Salger Expert
              Hi,

              @Nico: Die Konfiguration des Repositories, so dass nur eine Kopie der Pakete gehalten wird geht standardmäßig nur beim Anlegen eine neuen Repositories (Häkchen bei "Nur eine Kopie des Paketverzeichnisses halten"). Danach ist die Konfiguration unter "Repository-Eigenschaften" zwar lesbar aber nicht änderbar.

              Wenn man's trotzdem ändern möchte, dann geht das im Raw-Mode.
              Für das Kopieren der zu dem Zeitpunkt bereits vorhandenen Paketen im Filesystem (in allen Depots) ist man dann selbst zuständig.
              Und an der Stelle würde ich jedenfalls erst mal gründlich testen, ob danach auch alles incl. Distribution usw. sauber funktioniert.

              Ohne unsupportete Eingriffe müsste man für die Umstellung wohl ein neues Repository anlegen und die Pakete verschieben. Gefolgt von der Distribution an alle Standorte.
              Auch nicht wirklich schön, vor allem wenn man schon sehr viele Pakete und mehrere Standorte hat.

              Interessant wäre es auch nachträglich für reine Test-Repositories. Die kann man eher noch auch im laufenden Betrieb umstellen und bei der Entwicklung tun die Verzögerungen bei der Distribution besonders weh.

              Zu 1.: Da würde ich kein Problem erwarten, in dem gemeinsamen Paket- bzw. Revisionsverzeichnis liegen dann einfach die gezippte und die ungezippte Version. Die Distribution sollte dann einfach die gezippte verwenden.
              Daraus ergibt sich nebenbei auch, dass es so ohne Weiteres auch keine Platzersparnis gibt - es gibt weiterhin eine gezippte und eine ungezippte Version der Dateien nur dass die im gleichen Verzeichnis liegen. Dem kann abhelfen indem man die Paketdaten komprimiert hält (Site-Einstellung!), so dass die unkomprimierte Kopie wegfällt. Damit hat man dann nebenbei auch noch weniger Bandbreitenbedarf beim Staging auf die Clients.

              Zu 2.: Das verstehe ich nicht. Warum sollte die Gefahr bei nur einem Verzeichnis größer sein? Immerhin fällt ja ein (lokaler) Kopierschritt weg, die Wahrscheinlichkeit, dass beim Kopieren etwas schief geht sollte also eher geringer sein. An der Distribution über die WAN-Links in die Sites würde sich nichts ändern.

              @Michi: Wie was nicht supportet? Mit nur einem Verzeichnis zu arbeiten kann ich ganz normal beim Anlegen eines Repositories auswählen, also ganz ohne Eingriff in die Innereien. Ich gehe davon aus, dass das auf alle Fälle supportet ist. Ich vermute allerdings, dass es schon eine eher ungewöhnliche Konfiguration ist, so dass man natürlich auch unerfreuliche Überraschungen erleben kann
              Aber deswegen frage ich ja

              Ciao
                Klaus
              • 4. Re: Trennung Work / Install
                Michi Expert


                @Michi: Wie was nicht supportet? Mit nur einem Verzeichnis zu arbeiten kann ich ganz normal beim Anlegen eines Repositories auswählen, also ganz ohne Eingriff in die Innereien. Ich gehe davon aus, dass das auf alle Fälle supportet ist. Ich vermute allerdings, dass es schon eine eher ungewöhnliche Konfiguration ist, so dass man natürlich auch unerfreuliche Überraschungen erleben kann
                Aber deswegen frage ich ja

                Ciao
                  Klaus



                Hi Klaus,

                ich dachte, Du willst das Master Repository umkonfigurieren auf ein Verzeichnis. Da meinte ich es wäre eher nicht supportet (wissen tu ich es aber nicht). Bei weiteren kommt ja die Abfrage und es erledigt der Wizard gleich  ;-)
                • 5. Re: Trennung Work / Install
                  Klaus Salger Expert
                  Ah OK, da sind wir uns einig
                  • 6. Re: Trennung Work / Install
                    NicoS1 Master


                    Zu 2.: Das verstehe ich nicht. Warum sollte die Gefahr bei nur einem Verzeichnis größer sein? Immerhin fällt ja ein (lokaler) Kopierschritt weg, die Wahrscheinlichkeit, dass beim Kopieren etwas schief geht sollte also eher geringer sein. An der Distribution über die WAN-Links in die Sites würde sich nichts ändern.



                    Okay, bei uns läuft es so: Der Distributionsdienst auf dem Master Server, schiebt die gezippten Sourcen vom Master-Work ins Site Work. Dort übernimmt dann der auf dem Management Point eingerichtete Distributionsdienst und entpackt die ins Work geschobenen Zips ins Install.

                    Ich habe das eine oder andere Paket mit vielen kleinen Dateien, wo dieses Entpacken manchmal zu CRC Fehlern in den Dateien führt (nur vereinzelt).

                    Ich könnte mir vorstellen, das es nicht wirklich besser wäre, wenn anstatt den gezippten Sourcen die entpackten Sourcen distributiert werden.

                    Falls ich da nen kompletten Denkfehler habe, bitte nicht übel nehmen. Ich hab mich in das Thema noch nicht wirklich einlesen können... basiert aktuell nur auf Gedankengängen wie es aus meiner Sicht laufen würde.
                    • 7. Re: Trennung Work / Install
                      Klaus Salger Expert
                      OK, bei Push-Distribution in eine nicht-komprimierte Site würde ich auch erwarten, dass die Dateien unkomprimiert über die Leitung gehen.
                      Evtl. wäre es bei dem Szenario ganz interessant, komprimierte Sites zu verwenden. Dann sollte das Dekomprimieren erst auf dem Client stattfinden.
                      Das Dekomprimieren, die entpackte Kopie, den dafür nötigen Service und die entsprechende zeitliche Verzögerung könnte man sich in den dezentralen Sites dann sparen.
                      Das müsste zumindest bei einstufigen Distributionsstrukturen (z.B. sternförmig direkt in alle Sites) funktionieren.
                      Es gibt allerdings sicher komplexere Sitestrukturen. Und ob es da in jedem Fall noch zuverlässig funktioniert müsste man testen.

                      Rein interessehalber: Warum schiebst Du die Pakete per Push, also vom zentralen Distriservice, in die Sites wenn Du da ohnehin einen Distriservice hast, der auch genauso gut per Pull distribuieren könnte. Mit dem Pull würde man immerhin den zentralen Service entlasten. Gibt's da Firewalls, die einen Verbindungsaufbau von den Sites aus nicht erlauben?

                      Denkfehler werden hier (hoffentlich) grundsätzlich nicht übel genommen
                      Irren ist menschlich und auch das DSM verhält sich in der Realität nicht immer so, wie man es erwarten würde
                      Versuch macht kluch...

                      Ciao
                        Klaus
                      • 8. Re: Trennung Work / Install
                        Frank.Scholer Master
                        Hallo zusammen,

                        weil ich das Thema auch schon die ganze Zeit vor mir herschiebe (macht es jetzt Sinn oder macht es keinen), habe ich mich mal hingesetzt und versucht meine Gedanken zu strukturieren... weil es auch für das Forum viel zu lang geworden wäre, hab ich einen Blog-Artikel daraus gemacht (bin für Feedback natürlich wie immer sehr offen).

                        Auf jeden Fall sind meine Schlussfolgerungen, dass es in der Realität praktisch niemals Sinn macht, die Option "Nur eine Kopie des Paketverzeichnisses halten" auszuwählen, da es keinerlei Vorteile oder Ersparnisse bringt...

                        Grüße Frank
                        • 9. Re: Trennung Work / Install
                          MarkusMichalski Specialist
                          Hallo,

                          mit dem Windows Server 2012 bekommen wir endlich die transparente Deduplizierung für das Dateisystem. Damit sollte das erledigt sein: http://blogs.technet.com/b/filecab/archive/2012/05/21/introduction-to-data-deduplication-in-windows-server-2012.aspx

                          Gruß, Markus
                          • 10. Re: Trennung Work / Install
                            Klaus Salger Expert
                            Hallo Frank,

                            danke für die ausführlichen Betrachtungen zu dem Thema!
                            Ich erlaube mir hier mal einen Link einzufügen damit man's leichter findet.
                            https://www.nwc-services.de/service/blog/entry/gedanken-zu-nur-eine-kopie-des-paketverzeichnisses-halten
                            Nachdem ich keinen Blog schreibe entleere ich mein Hirn weiterhin ins Forum

                            Ich gehe ohne das überprüft zu haben mal davon aus, dass es genau so stimmt wie Du's geschrieben hast.
                            Dann muss ich 2 Dinge korrigieren, die ich vorher angenommen habe (so viel zum Thema "Irren ist menschlich" ) :
                            1. Auch bei nur einem Paketverzeichnis muss ich bereits lokal die Distribution abwarten, d.h. die Vorbereitung alleine reicht nicht, der Distriservice muss die unkomprimierte Kopie im Rev-Dir erzeugen.
                            2. Die Distribution in eine andere Site erfolgt immer komprimiert (innerhalb der gleichen Site ist das ja nicht der Fall).

                            Wie Du auch in Deinem Blogpost schreibst bleibt die Möglichkeit Repositories mit nur einem Paketverzeichnis mit komprimierten Sites zu kombinieren um Platz zu sparen und Distributionsschritte zu reduzieren.
                            Und da möche ich Deinem Fazit "bringt nix" widersprechen. Diese Kombination finde ich schon interessant.

                            Reduzierung der Speicherplatzbedarfs um mindestens 50% (solange ich keine Deduplizierung habe), Reduzierung des Paket-Distributionstraffics innerhalb der Sites um bis zu 100% - das klingt doch ganz gut. (Was heißt hier "überschaubares Einsparpotential"? :confused

                            Und was spricht dagegen?
                            Temporär mehr Speicherplatzbedarf und höhere CPU-Auslastung auf dem Client wegen des Auspackens der Pakete.
                            Kann bei älteren Clients ein Showstopper, bei ausreichend leistungsfähigen Clients aber auch "No Problem" sein.
                            Aktuell ist das sicher eine ungewöhnliche Konfiguration und damit dürfte das Risiko unerwartet auf Probleme zu stoßen größer sein als bei der Standardkonfiguration.
                            Daher wäre es natürlich wertvoll neben den theoretischen Überlegungen auch Feedback zu praktischen Erfahrungen zu bekommen - wenn es die denn gibt.

                            Szenario1: Paketentwicklung
                            Anlegen einer neuen komprimierten Site und ein neuen Development-Repository -> geringer Aufwand, geringes Risiko -> kein Problem.
                            Wenn man's genau nimmt würden die Bedingungen während der Entwicklung nicht exakt denen in der Produktion (mit 2 Paketverzeichnissen + unkomprimierten Sites) entsprechen, scheint mir aber akzeptabel.

                            Gut, das Probem wäre im Wesentlichen auch erledigt, wenn FrontRange das seit NetInstall 5.0 meistgewünschte (?) Feature einbauen würden, den "Replicate Now"-Button (am besten analog der Vorbereitung der Distribution nur für genau das gewählte Paket).
                            Neustart des Distriservice kann ja auf die Dauer nicht die Lösung des Problems sein und alle Pakete mit extrem kurzem Pollingintervall zu prüfen nur weil ich ab und zu mal ein Paket erstelle ist auch Overkill.

                            Szenario2: Neuinstallationen oder Umstellung einfacher (z.B. Single Site) Umgebungen
                            Wenn ich das von Anfang an so anlege wäre es kein zusätzlicher Aufwand und auch die Umstellung von kleinen, übersichtlichen Umgebungen bekommen man wahrscheinlich noch mit vertretbarem Aufwand hin.

                            Ich werde jetzt sicher nicht anfangen, große, komplexe Umgebungen mal eben umzustellen aber Szenario 1 schein mir doch recht interessant. Selbst wenn sich dabei herausstellen sollte, dass es irgendwo dann doch hakt, könnte man das verschmerzen. Und wenn's gut funktioniert, dann kann man auch an Szenario 2 gehen.
                            Warum nicht?

                            Ciao
                              Klaus
                            • 11. Re: Trennung Work / Install
                              Klaus Salger Expert
                              [QUOTE=m.michalski;38090]Hallo,
                              mit dem Windows Server 2012 bekommen wir endlich die transparente Deduplizierung für das Dateisystem....
                              Gruß, Markus

                              Hi Markus,

                              ja, das sollte helfen. Mit NetApp und Konsorten geht das ja heute auch schon. Hat aber nicht jeder und eine Lösung für die Reduzierung von Distributionsschritten und entsprechenden Wartezeiten fände ich auch allein schon recht interessant.

                              Ciao
                                Klaus
                              • 12. Re: Trennung Work / Install
                                Frank.Scholer Master
                                Hallo Klaus,

                                1. Auch bei nur einem Paketverzeichnis muss ich bereits lokal die  Distribution abwarten, d.h. die Vorbereitung alleine reicht nicht, der  Distriservice muss die unkomprimierte Kopie im Rev-Dir erzeugen.


                                So würde ich das sehen, ja.

                                2. Die Distribution in eine andere Site erfolgt immer komprimiert (innerhalb der gleichen Site ist das ja nicht der Fall).


                                Das definitiv! Das war aber "schon immer" so (also auch zu NI 5.x Zeiten)...

                                Und was spricht dagegen?


                                Die - natürlich inoffizielle - Aussage, die ich mal auf dem kleinen Dienstweg gekriegt habe, dass das Szenario nicht getestet würde und man lieber die Finger davon lassen soll ;-)

                                Außerdem ist es problematisch, da ja eigentlich seit DSM 7 die Userteile direkt vom Share nachinstalliert werden, wenn sich das Paket nicht im Repository-Cache befindet. Das kann natürlich mit komprimierten Paketdateien nicht funktionieren. Ich habe jetzt keine großartigen Tests gemacht, wie sich der Client dann verhält, aber ich würde vermuten / befürchten, dass er dann das komplette Paket nochmal staged... und dann ist dein Traffic-Vorteil natürlich ganz schnell dahin.

                                Wenn man's genau nimmt würden die Bedingungen während der Entwicklung  nicht exakt denen in der Produktion (mit 2 Paketverzeichnissen +  unkomprimierten Sites) entsprechen, scheint mir aber akzeptabel.


                                Hmm, da hätte ich Bauchschmerzen damit und würde das meinem Kunden auch kommunizieren.

                                Neuinstallationen oder Umstellung einfacher (z.B. Single Site) Umgebungen


                                Was sparst oder gewinnst du dabei? Vielleicht 100 GB auf'm Storage (in solchen eher kleinen Umgebungen). Wenn's daran hängt, dann hab ich eh Bedenken ob der gesamten Umgebung oder des Konzepts... muss ja für kleine Umgebungen nicht unbedingt teurer SAN-Storage sein - ein NAS oder sogar Local Storage tut's in solchen Umgebungen ja auch und das ist nun wirklich nicht der Kostentreiber...

                                Naja, wie auch immer - ich dachte auch immer, man könnte massenhaft Platz sparen und dass es eben seit v6 diese Trennung überhaupt nicht mehr braucht. Und jetzt, wo ich es mal soweit durchgedacht hab, stelllt sich raus, dass in "normalen" Umgebungen die Trennung nur für etwas mehr Komplexität sorgt, aber dadurch eben kein Platz verschwendet wird (im Gegensatz zur Alternative, WORK und INSTALL eben nicht mehr zu trennen) und das ist ja auch schonmal eine erfreuliche Erkenntnis.

                                Grüße Frank
                                • 13. Re: Trennung Work / Install
                                  Klaus Salger Expert


                                  Und was spricht dagegen?




                                  Die - natürlich inoffizielle - Aussage, die ich mal auf dem kleinen Dienstweg gekriegt habe, dass das Szenario nicht getestet würde und man lieber die Finger davon lassen soll ;-)



                                  OK, klar, das ist ein Argument. Möchte natürlich nicht riskieren, dass mir das Ganze auf die Füße fällt. Vorsicht ist also geboten.


                                  Außerdem ist es problematisch, da ja eigentlich seit DSM 7 die Userteile direkt vom Share nachinstalliert werden, wenn sich das Paket nicht im Repository-Cache befindet. Das kann natürlich mit komprimierten Paketdateien nicht funktionieren. Ich habe jetzt keine großartigen Tests gemacht, wie sich der Client dann verhält, aber ich würde vermuten / befürchten, dass er dann das komplette Paket nochmal staged... und dann ist dein Traffic-Vorteil natürlich ganz schnell dahin.



                                  Ah ja, daran hatte ich gar nicht gedacht.
                                  Das wäre dann aber ein Problem, das man in Remote Sites (wenn sie komprimiert sind) auch hat und da ist das erneute Stagen natürlich noch unangenehmer.
                                  Wäre dann wohl eine Überlegung wert, auch Remote Sites NICHT komprimiert anzulegen auch wenn die Installation von NUR Benutzerteilen remote wahrscheinlich gar nicht sooo oft vorkommt.
                                  Mit der direkten Installation aus dem Share ohne Staging dürfte es in komprimierten Sites aber wohl auch nicht mehr funktionierien.
                                  Das ist zwar nicht der Regelfall aber doch eine Möglichkeit, die ich gerade mit Hilfe der Hardlinks bekommen habe und auf die ich dann doch nicht so gerne verzichten möchte.


                                  Hmm, da hätte ich Bauchschmerzen damit und würde das meinem Kunden auch kommunizieren.



                                  Naja, es ist die Frage, ob man erwarten kann, dass ein Paket, das in einer komprimierten Site funktioniert in einer nicht komprimierten Site nicht mehr funktioniert.
                                  Das würde ich so nicht erwarten - eher anders rum.
                                  Und die Installation über eine komprimierte Remote-Site hat man auch gleich mitgetestet - OK, wenn ich keine komprimierten Remote Sites mache, kann ich mir das auch sparen

                                  Für mich stellt sich die Situation damit so dar, dass komprimierte Sites und damit auch die 1-Paketverzeichnis-Konfiguration in produktiven Umgebungen im Regelfall nicht erstrebenswert sind.
                                  Das Szenario mit einer komprimierten Entwicklungssite mit Entwicklungsrepository mit nur einem Paketverzeichnis werde ich mir im Lab mal näher anschauen.
                                  Wenn dabei rauskommt, dass man bei der Entwicklung nie wieder die Distribution abwarten muss wäre ich schon sehr zufrieden.

                                  Einstweilen vielen Dank für die muntere Diskussion - ich sehe schon viel klarer.
                                  Weiter Diskussionsbeiträge sind natürlich weiterhin erwünscht.

                                  Ciao
                                    Klaus