Malá firma - jediný AD server? Jak případně obnovit na jiné železo?

JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Jednak to neni pravda, a druhak v ty licenci ma zcela jiste napsano i to, ze az mu ten HW chcipne, tak si musi stejne koupit widle novy ....

Jo, ale jak definujes novy HW? Vyhori mobo, vymenim ho. Vyhori disk, vymenim ho. Nakonec zbyde jen bedna, ale je to prece porad ten samy pocitac a mam na nem nalepku, ne?


krallinuxu1

AD pro sest lidi? ...jako strilet brabce kulometem.

AD zrus a v pripade obnovy si tam tech sest jzivatelu nacvakas rucne.

j

Jo, ale jak definujes novy HW? Vyhori mobo, vymenim ho. Vyhori disk, vymenim ho. Nakonec zbyde jen bedna, ale je to prece porad ten samy pocitac a mam na nem nalepku, ne?
Je uplne jedno jak to definuju ja, soudruzi v M$ to maji jako libovolna soucast = hdd/mb/cpu ...

krallinuxu1

Jednak to neni pravda, a druhak v ty licenci ma zcela jiste napsano i to, ze az mu ten HW chcipne, tak si musi stejne koupit widle novy ....

Jo, ale jak definujes novy HW? Vyhori mobo, vymenim ho. Vyhori disk, vymenim ho. Nakonec zbyde jen bedna, ale je to prece porad ten samy pocitac a mam na nem nalepku, ne?
Ale to se tazatel nechysta delat. on vymeni cela streva

KarelKarlovic

Tak řekněme, že u narychlo nahozenýho stroje jenom proto, aby to rychle zase fungovalo, by mi legálnost byla ukradená. Ta by se začala řešit až po obnově - jestli půjde zprovoznit původní železo, nebo se koupí nový stroj.

Dotaz byl směřován hlavně na to, jestli lze zaručeně doménu obnovit na jiné železo bez druhého běžícího AD DC (Samba 4 je krkolomná).


qwertz

Možná je to úplně idiotský nápad, uvažoval jste o tom, že to přesunete na Linux?

AD se tam stejně nepoužívá, jediný problém by tak mohl být s tím MSSQL a IIS, pokud tedy na tom běží něco Microsoft specific.
Odpadl by problém s licencema, virtualizací, migrací a recovery. Účty lze řešit přes LDAP, zbytek máte stejně externě. A to co je závislé na MS by skončilo ve virtuálu (má to jen výhody, až na nutnost koupit licenci umožňující virualizaci).

JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Dotaz byl směřován hlavně na to, jestli lze zaručeně doménu obnovit na jiné železo bez druhého běžícího AD DC (Samba 4 je krkolomná).

A co kdyby AD nebylo na widloserveru, ale na dvou RPi - hlavni a zalozni? Widle by delaly jen souborovy a aplikacni server a vy byste nemusel resit nejake problemy s replikaci mezi ruznymi verzemi AD, ktere vam brani nasadit RPi jako zalohu k widlovemu AD. A obnova by pak spocivala ve zkopirovani jednoho souboru nebo v cem to SAMBA drzi, k cemuz by dochazelo jednou za X let, kdyz vam vydoutna SD karta.

MP

Dotaz byl směřován hlavně na to, jestli lze zaručeně doménu obnovit na jiné železo bez druhého běžícího AD DC (Samba 4 je krkolomná).

A co kdyby AD nebylo na widloserveru, ale na dvou RPi - hlavni a zalozni? Widle by delaly jen souborovy a aplikacni server a vy byste nemusel resit nejake problemy s replikaci mezi ruznymi verzemi AD, ktere vam brani nasadit RPi jako zalohu k widlovemu AD. A obnova by pak spocivala ve zkopirovani jednoho souboru nebo v cem to SAMBA drzi, k cemuz by dochazelo jednou za X let, kdyz vam vydoutna SD karta.

To neni dobre reseni. Pokud by Windows delaly soubor/app server, tak uz potrebuje odpovidajici licence. A AD na Sambe neni jen 1 soubor. Navic, replikace nefunguje na vsech urovnich. K tomu, zadny powershell, atd.

OP by si mel ujasnit, jake bude schema aplikacnich pristupu. Hodla nasadit i treba SSO? Ano, pro 6 uzivatelu zni AD jako overkill, ale v pripade jednotneho pristupu k aplikacim apod. to muze mit vyrazenjsi dopad. Zvlaste, pokud by se mela firma rozrustat.

Lol Phirae

No já se obávám, že

v pripade obnovy si tam tech sest jzivatelu nacvakas rucne.

je totální nepochopení technologie. Ono už jen obíhat těch 6 počítačů a každý zvlášť nastavovat, zatímco bych to v doméně bez problémů udělal přes GPO, je zcela padlé na hlavu. Nastavovat nové heslo na X různých místech je rovněž fakt super zážitek.

qwertz

heslo řeší LDAP bez ohledu na OS. Problém jsou ty GPO, ale i to se asi dá řešit:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/sssd-gpo

Sleduji tuto diskusi, ale zdá se mi, že každý mluví o něčem jiném.

Základní otázkou je, jestli používat AD, nebo ne. Za mě je AD příjemná věc pro správu v situaci, kdy je zákazník ochoten podřídit se pravidlům a získat úspory na usnadnění správy. Pokud není, pak je vhodnější workgroup.

SQL a terminal určitě nemají co dělat na AD/GC.

Osobně bych preferoval virtualizaci, je jedno, jestli vSphere nebo Hyper-V. Uvnitř aspon 2 virtuálky: AD/GC na jedné, zbytek na druhé. SQL by podle mě nemělo být ani na RDS, protože RDS vyžaduje více správy a restartů, a to není pro SQL vhodné.

Pokud je limitujícím faktorem cena hardware a licencí, pak nemá smysl vůbec o ničem diskutovat. Firma o 6 zaměstnancích musí vydávat cca 200 tis. Kč měsíčně na mzdách a odvodech (držím se spíš při zemi), a řešit, jestli server s životností 5 let má stát 30, 50 nebo 90 tis. Kč je zcela nemístné. Pokud je zákazník takového ražení, spadá do kategorie nebosloužitelných.

Přechod na Sambu samozřejmě možný je, ale když bych vzal správnou odměnu admina 1000 Kč / hod. a více, pak se mi Microsoft technologie zdají jako levnější řešení. Pokud zákazník hledá admina za 300-500 Kč / hod., spadá opět do kategorie neobsloužitelných zákazníků.

KarelKarlovic

Možná se hodí trochu zopakovat, co bylo rozeseto po více postech:

Aktuálně není doména potřeba. HW/SW by nakoupit šel, pokud by k tomu byl důvod. Až bude doména potřeba, nevidím jako problém zainvestovat potřebný HW/SW a zavést ji.
Toto téma řeším proto, jestli bych si pomohl tím, že ji založím hned teď (a trochu si usnadním práci) se stávajícím vybavením (když budu nastavovat nový router, vyhazovat staré switche a dělat inventuru SW), nebo se tím dostanu do slepé uličky v případě nějakého problému a budu se proklínat, proč jsem to dělal.

Toto téma řeším proto, jestli bych si pomohl tím, že ji založím hned teď (a trochu si usnadním práci) se stávajícím vybavením (když budu nastavovat nový router, vyhazovat staré switche a dělat inventuru SW), nebo se tím dostanu do slepé uličky v případě nějakého problému a budu se proklínat, proč jsem to dělal.

Do slepé uličky? Zavést doménu bude vždy podobně náročné, bude to o oběhání všech PC a nastavení politik domény. Když s tím začnete hned, rozloží se to v čase. Když až v době potřeby, asi se trochu opupínkujete, co všechno je potřeba udělat. Páka zmenší potřebnou sílu, ale po delší dráze, výsledná práce však zůstává stejná. Je to podobné, jen se nebavíme o síle a dráze, ale úpornosti a čase.

KarelKarlovic

...nebo se tím dostanu do slepé uličky v případě nějakého problému...
Do slepé uličky?
v případě nějakého problému s jediným AD DC
Slepá ulička při případném pádu stroje a nemožnosti/komplikovanosti/náročnosti obnovy do funkčního stavu.

Doména:
Práce s rozjetím domény teď, otestovat recovery scénář AD DC a SQL
Nové stroje se budou rovnou přidávat do domény, méně práce než teď skupina a pak připojení do domény
Méně obíhání PC (průběžně)
Jeden login
Složí se server, bez druhého AD DC jsem v háji. I když rozjedu SQL pro IS, bez AD DC se do něho nikdo nepřihlásí, takže ještě všude předělávat loginy.

Workgroup:
Nemusím teď testovat recovery scénář AD, stačí SQL
Více obíhání PC
Udržování loginů na více místech
Složí se server - kdekoliv rozjedu SQL pro IS a ručně tam hodím 6 loginů.

Mít jistotu, že se server nesloží nebo se dá jednoduše AD DC obnovit, tak doménu rovnou zakládám, ale případné potíže při smrti serveru budou mnohem větší, než kolik bych průběžně ušetřil času při tak málo uživatelích.

Žádat o nákup HW a SW, abych to teď dýl rozjížděl a neřekl jim, za jak dlouho mi to začne práci šetřit (protože nevím, jak rychle můžou růst, a kdy se to zlomí) není na místě. Pozdější zavedení sice bude časově náročnější, ale jednoznačně odůvodnitelné jak ohledně času, tak nákupu HW/SW. A kdyby náhodou dlouho stagnovali, tak to budu dělat zbytečně.

JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Udržování loginů na více místech

Jo, ale asi nemusim udrzovat vsechny loginy na vsech strojich. U kazdeho sedi nejspie jeden clovek, ledaze by to u nich vyadalo tak, ze se kazde rano strhne rvacka, kdy se perou o to, kdo kde bude sedet.

Tady by bylo zajimave, jestli jdou ze stroje loginy vyexportovat a zase naexportovat z CLI. Pak by to slo hodit na server do ro souboru a kazdy stroj by si to pri spusteni importoval a bylo by. To by se zvladlo pres par batchu.