Jump to content

NilsK

Expert Member
  • Content Count

    13,681
  • Joined

  • Last visited

Posts posted by NilsK


  1. Moin,

     

    nein, du installierst nichts auf dem Host, nur Hyper-V. USB-Drucker bekommst du dann nicht an die Printserver-VM weitergeleitet, aber USB-Drucker sind für gemeinsame Nutzung auch schlicht ungeeignet. Gib im Zweifel 40 Euro für einen USB-Printserver aus.

     

    [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net]
    https://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/

    - in deinem Fall ist besonders der letzte Absatz relevant

     

    Dienste auf VMs aufzuteilen, ist als Grundprinzip gut. In so einem Heimsetup sind die Anforderungen aber typischerweise andere. In deinem Fall sehe ich keinen Sinn darin, überhaupt mit mehreren Windows-VMs zu arbeiten; weder die zu erwartende Last noch die vermutlich erforderliche Ausfallsicherheit geben das her. Die genannten Dienste wird man problemlos gemeinsam auf einer VM betreiben können und spart sich dadurch einiges an Aufwand und Overhead.

     

    Wie lizenzierst du das eigentlich? Eine Windows-Server-Lizenz plus CALs scheinen mir für das, was du da effektiv vorhast, ein ziemlich teurer Ansatz zu sein.

     

    Gruß, Nils

     


  2. Moin,

     

    mach was du willst ... wozu auch immer, das erschließt sich mir nicht. Muss es ja auch nicht. (Veeam in so einer Umgebung?!)

     

    Trotzdem könnte es sinnvoll sein, ein wenig Planung und ein paar Gedanken in die Umgebung zu stecken. Ein altes Notebook ist nun mal ein altes Notebook, auch wenn du noch ein paar GB RAM reinbekommst (was vermutlich stark begrenzt sein dürfte, bei 16 GB ist mit Sicherheit Schluss). Ich habe, wie gesagt, keine Ahnung, wozu du die VMs brauchst. In einer Heimumgebung schätze ich bei oberflächlicher Betrachtung aber mal, dass insgesamt zwei oder drei VMs ausreichen. Bei etwa 28 GB RAM, die du verteilen kannst, ist das dicke genug.

     

    Gruß, Nils

     


  3. Moin,

     

    ähm - was willst du mit einem 6-GB-Rechner als Host? Da bekommst du mit Glück eine VM ordentlich ans Laufen, hast aber  immer noch nur ein altes Notebook drunter. Lass das weg und besorg dir lieber noch 32 GB für den Server. Dann fällt wahrscheinlich auch das Gehampel weg.

     

    Wenn du Windows-Server-VMs betreibst, brauchst du ja ohnehin Lizenzen dafür. Dann entfällt der Grund, den kostenlosen Hyper-V-Server einzusetzen. Richte den Host mit  einem richtigen Windows-Server-OS ein (das du ja sowieso lizenzieren musst) und verwalte den Host bequem über das lokale GUI. Dann brauchst du auch keine Domäne und keinen Remotezugriff auf den Host.

     

    Gruß, Nils

     

    • Like 2

  4. Moin,

     

    Hyper-V-Hosts remote zu verwalten, ist in deinem Aufbau eine holprige Angelegenheit. Einfacher wäre es, wenn du für den Zweck eine AD-Domäne einrichten würdest. Vielleicht würde es auch schon helfen, mit festen IP-Adressen und internem DNS zu arbeiten, aber dann wäre eben eine Domäne auch kaum noch Mehraufwand.

     

    Was sollen denn für VMs laufen und wozu dient das Ganze? Vielleicht stellt sich ja heraus, dass du ohnehin eine Domäne brauchst, dann kann man sich das ganze Gebastel vorab schenken.

     

    Gruß, Nils

     


  5. Moin,

     

    die Gruppe "Konten-Operatoren" will und sollte man nicht benutzen. Sie ist insgesamt viel zu hoch berechtigt.

     

    @Bosco: was du suchst, nennt sich "administrative Delegation". Wenn du keine Erfahrung damit hast, ist externe Beratung sicher sinnvoll, denn sowas wird auch in kleineren Umgebungen schnell komplex. Und es ist  natürlich sensibel in Bezug auf die Sicherheit.

     

    Im ersten Schritt solltet ihr genau (!) definieren, was die Rolle denn tun bzw. können soll. Auf der Basis kann man dann prüfen, wo welche Berechtigungen nötig sind. Ob man dafür dann separate Tools braucht, lässt sich auch nur auf Basis der exakten Anforderungen bewerten.

     

    Gruß, Nils

     

     

     


  6. Moin,

     

    vor 1 Minute schrieb MVPL:

    Genau das habe ich gemacht.  

    dann aber vermutlich nicht richtig ... oder nicht den richtigen Account.

     

    Zitat

    Nein leider nicht. 

    Um was für ein Gerät handelt es sich denn?

     

    Zitat

    Es soll die Datenbank eines Archivs darauf gespeichert werden. Also eigentlich nein. 

     Aber es geht schon um Unternehmensdaten? Dann sollte die Umsetzung auch Hand und Fuß haben.

     

    Gruß, Nils

     

    • Like 1

  7. Moin,

     

    wenn das NAS nicht in der Domäne ist, kannst du doch den Service Accounts eines anderen Servers gar keine Berechtigungen geben. Eine Möglichkeit wäre, dass du auf dem NAS einen User anlegst, der genauso heißt und dasselbe Kennwort hat wie der Service Account auf dem SQL Server.

     

    Ich halte es aber für fraglich, dass du mit dem Konstrukt glücklich wirst. Eine 30-TB-Datenbank will man nicht per SMB 2 oder gar SMB 1 auf einem NAS ansprechen. Wenn das NAS tatsächlich nur für diesen Zweck da ist, sollte man es als Storage nutzen und per iSCSI anbinden. Bietet das Gerät diese Möglichkeit?

     

    Und: Von was für einer Nutzung sprechen wir hier? Ist das was Unternehmenskritisches?

     

    Gruß, Nils

     


  8. Moin,

     

    ja, ein Netzwerkkabel wird schon im Spiel sein ;-) - aber darum geht es nicht, sondern um das Protokoll, was für den Zugriff verwendet wird. Ich nehme einfach mal an, dass das NAS wie ein NAS angesprochen wird, also wie ein Dateiserver. Das ist dann das Protokoll SMB. Vorsicht aber, manche einfachen NAS verwenden immer noch SMB 1.0, und das ist noch weniger für diese Art des Zugriffs geeignet.

     

    Mit "das NAS wird anders genutzt" meine ich, ob es parallel auch noch normale Dateizugriffe darauf gibt. Die erzeugen natürlich zusätzliche Last, was tendenziell den Datenbankzugriff weniger zuverlässig macht. Das würde man bei einer "ernsthaft" produktiv genutzten Datenbank vermeiden wollen.

     

    Wenn du die Datenbank also auf diese Weise anbinden willst, dann wählst du im SQL Server Management Studio per Rechtsklick auf den Eintrag "Datenbanken" den Befehl "Anfügen", dann den Button "Hinzufügen" und gibst dann oben den UNC-Pfad zur .mdf-Datei an: \\server\share\ordner\datei.mdf. So sollte die Datenbank sich einbinden lassen.

     

    Gruß, Nils

     

    • Haha 1

  9. Moin,

     

    normalerweise arbeitet SQL Server (wie die meisten Datenbanksysteme) mit Blockstorage, d.h. mit lokalen Platten oder Volumes, die mit einem Blockprotokoll wie Fibre Channel oder iSCSI eingebunden sind. Seit einigen Jahren ist dafür auch ein Zugriff auf SMB-Dateifreigaben möglich (ab SMB 2.0). Da diese Art des Zugriffs aber eine Reihe von Einschränkungen hat, steht das unter gewissen Grenzen.

     

    Um eine Datenbank von einer Dateifreigabe einzubinden, muss man diese mit einem UNC-Pfad ansprechen. Per Laufwerksbuchstaben eingebundene "Netzlaufwerke" werden nicht unterstützt, weil diese Einbindung immer benutzerspezifisch ist.

     

    Wenn die Datenbank produktiv genutzt werden soll, ist eher davon abzuraten, dass diese auf einem NAS liegt, wenn dieses NAS auch noch anders genutzt wird.

     

    Gruß, Nils

     


  10. Moin,

     

    verabschiede dich bei Datenbanken von der Denke "das muss man tun". Dafür sind Datenbanken in ihrer Nutzung zu unterschiedlich. Was für Datenbank A unabdingbar ist, kann für Datenbank B sinnlos oder sogar hinderlich sein.

     

    Die Index-Fragmentierung kann ein Thema sein, wenn eine Datenbank in großem Umfang verändert wird. Selbst dann sind Pauschalregeln aber (leider) selten zielführend. Wenn dein ERP-Dienstleister gut ist, kann er dir Empfehlungen geben, denn ohne Kenntnis der Applikation sind Optimierungen ein weitgehend aussichtsloses Unterfangen.

     

    Gruß, Nils

     


  11. Moin,

     

    ich habe keine Umgebung an der Hand, um das auszuprobieren. Der übliche Weg wäre aber, dass du dir mit einem Get-Befehl (vermutlich Get-ADGroup)  alle gewünschten Objekte in eine Variable lädst. Die kannst du dann z.B. mit foreach durchgehen und den jeweils gewünschten Wert mit $_.<Eigenschaft> an das Ziel-Cmdlet (also wohl Enable-DistributionGroup) übergeben.

     

    Dass das organisatorische Folgen haben kann, ist hier ja schon diskutiert worden. Deine bisherigen Probleme bei der Umsetzung hast du bislang allerdings auch noch nicht beschrieben.Wenn es da zu Fehlern kommt, nenne es bitte genau.

     

    Gruß, Nils

     


  12. Moin,

     

    es kann durchaus Sinn ergeben, sich vorher mit den Dingen zu beschäftigen.

     

    Die Idee bei RDS ist, dass die Anwendungen auf dem Server laufen, an den Client werden nur die Bildschirminhalte übertragen. Vom Client zum Server gehen die Tastatur- und Mauseingaben. Jeder User hat seine Session auf dem Server. Der Anwender braucht dann nicht mal einen vollwertigen Rechner, sondern es reicht ein Thin Client. Dafür hat man auf dem Server auch nur eine Installation zu pflegen (nicht zehn plus zehn Full-Clients wie in deinem Modell).

     

    Ob das zu den Anforderungen passt, kann man dann bewerten, wenn man die kennt. Da du dazu nichts sagen willst, ist für mich hier Schluss.

     

    Gruß, Nils

     


  13. Moin,

     

    nimm es mir nicht übel, aber das Design ist ... nicht gut.

     

    In so einer Umgebung wird ein SQL Server nicht so viel I/O erzeugen, dass er so ein Monster-RAID brauchen würde, schon gar nicht exklusiv. Exchange ist in der Hinsicht unkritisch.

     

    Einen SQL Server würde ich nie mit anderen Funktionen kombinieren. Macht also schon drei VMs. Der DC sollte ebenfalls separat sein, macht vier. Ein DC ist für so eine Umgebung zu wenig, macht also entweder fünf VMs oder (besser) einen zusätzlichen kleinen Server als zweiten DC.

     

    Exchange niemals per Ex- und Import migrieren, wenn es keinen zwingenden Grund gibt - den gibt es hier offenkundig nicht.

     

    Da der Server schon da ist: Mach entweder ein Volume aus den SSDs und pack da alles drauf. Das ist bei weitem schnell genug. Wenn du unbedingt willst, nimm ein RAID-10. Oder mach drei RAID-1 draus, ist aber am Ende wohl nur umständlicher. Was macht ihr eigentlich, wenn der Host mal ausfällt oder Updates braucht?

     

    Vielleicht wäre ein wenig externe Beratung vor Projektbeginn eine gute Idee gewesen ...

     

    Gruß, Nils

     

    • Like 1

  14. Moin,

     

    willkommen an Board!

     

    Ich bin einigermaßen erstaunt - wer hat  denn da das Konzept und das Sizing gemacht? Virtuelle Desktops kann man machen, aber die Technik ist nicht umsonst eher exotisch, weil sie bei näherer Betrachtung nur selten Vorteile bringt. Welches Ziel wird damit denn verfolgt?

     

    Dann: 40 Cores?! Was habt ihr mit den VDI-Desktops denn vor? Gerade VDI gilt in aller Regel als Paradebeispiel für sparsame Ressourcennutzung. Rechnerisch hättet ihr vier Cores pro VM quasi exklusiv - wozu sollen die das denn brauchen? Ich wäre sehr erstaunt, wenn man wirklich mehr als, sagen wir, 8 Cores bräuchte. Und selbst damit könnte man einzelnen VMs zwei oder vier virtuelle CPUs geben (wozu auch immer), die werden sie ja nicht alle gleichzeitig zu 100% auslasten.

     

    Leider scheint mir, als seien im Zeitalter der Multi-Core-Monster-CPUs die grundlegenden Designregeln virtueller Umgebungen in Vergessenheit geraten.

     

    Was die Lizenzierung angeht: Du musst auf dem Server  alle Cores lizenzieren. Bleibt es bei 40 Cores, dann musst du in Summe 20 Core-Lizenzpakete haben, weil jedes zwei Cores abdeckt.

    RDS-Lizenzen brauchst du m.W. nicht, denn RDS wird hier ja gar nicht verwendet. (Obwohl es in vielen VDI-Umgebungen die bessere Wahl wäre.)

    CALs brauchst du nur dann, wenn weitere Windows-Dienste unter Windows Server 2019 genutzt werden. Wie sieht denn der Rest der Infrastruktur aus? Für die bislang diskutierten "reinen" Client-VMs bräuchtest du keine Server-CALs. Ist aber unwahrscheinlich, dass es dabei bleibt.

    Windows 10 Pro hingegen wird nicht reichen. Du brauchst eine Lizenzvariante mit Zugriffsrecht auf die virtuelle Instanz. Das heißt entweder Software Assurance für jeden Client oder jeweils eine separate VDA-Lizenz.

     

    Alles ohne Gewähr, aber zumindest ist das bisher nach meinem Eindruck eher Käse. Das gilt auch für die Grundidee - wenn ich du wäre, würde ich mich da noch  mal eingehend beraten lassen, und zwar nicht vom Disti, sondern von jemandem, der sich mit VDI auskennt.

     

    Gruß, Nils

     


  15. Moin,

     

    als "unzulässig" könnte Microsoft es nur bezeichnen, wenn es gegen Lizenzbestimmungen verstößt. "Nicht supported" bedeutet: wenn "sowas" gemacht wird, leistet der Hersteller keine Unterstützung dafür - typischerweise weder für Probleme, die direkt aus "sowas" entstehen (hier etwa: die Replikation funktioniert nicht), meist aber ausgedehnt auf jede Art von Problem, auch wenn sie nur sehr indirekt mit "sowas" zu tun hat (Beispiel: der Mailversand klappt nicht).

     

    Wenn man Lust hat, "sowas" dann selbst zu supporten, hält einen Microsoft nicht davon ab. Nur kann man dann eben nicht bei Microsoft anrufen, wenn was klemmt (um vorzubeugen: doch, kann man schon, die werden aber sehr bald das Gespräch beenden). Da ein solcher Zustand für die meisten Unternehmen indiskutabel ist, kommt "nicht supported" schon nah an "unzulässig" heran.

     

    Gruß, Nils

     

    • Like 1
×
×
  • Create New...