Re: Domeny windows

Tomasz Onyszko schrieb:
> Tomasz Chmielewski wrote:
>
>> biorac pod uwage mozliwosc konfliktu, i to, ze ktorys z masterow byl
>> rozlaczony, takie kryteria jak numer zmiany czy informacje o
>> zreplikowanych obiektach sa po prostu w takich przypadkach
>> nieprzydatne do rozwiazania konfliktu - one sluza do normalnej
>> replikacji.
>
>
> hmm .. no co ty nie powiesz :) sorki ale jezeli tak to wychodziloby ze
> cale AD opiera sie na magii. Zamiast krytykowac proponuje na poczatek
> doczytac. To ze OpenLDAP nie potrafi czegos takiego zrobic nie oznacza
> ze inni producenci (niekoniecznie chodzio o AD) takiego problemu lepiej
> lub gorzej nie rozwiazali.
>
> Kilka szybkich linkow odnosnie AD:
> http://www.comptechdoc.org/os/windows/win2k/win2kadrepl.html

no czyli jest zasadniczo, tak jak pisalem, decyduje "timestamp".
a w przypadku konfliktu i w tym wypadku, o zmianie decyduje serwer o
najwyszszym ID, czyli jak w modelu master-slave.
nic nowego.
za to sporo narzutow, by utrzymac prawidlowa prace multimaster.

> Najlepszy opis mechanizmow rozwiazywania konfliktow w przypadku
> replikacji jak dotad znalazlem chyba w "Inside Active Directory 2'nd
> Edition" do ktorej to lektury zachecam.

nie mialem okazji.

>> jedynym obiektywnym kryterium w przypadku konfliktow moze byc czas, w
>> ktorym nastapila zmiana.
>> w takim przypadku nalezy byc absolutnie pewnym, ze zegarki na
>> masterach chodza *absolutnie* w identycznym tempie; nawet male roznice
>> w czasie (dziesiate czesci sekundy) moglyby spowodowac skasowanie
>> niewlasciwych danych.
>> oczywiscie, wszystko zalezy od srodowiska, jakie tam sa zmiany i jak
>> czesto one nastepuja.
>>
>> w zwyklych kontrolerach domeny raczej czegos tak "mission critical"
>> nie ma, wiec problem zasadniczo nie istnieje.
>
>
> Twierdzisz ze nie ma czegos takeigo jak mission critical w kontrolerach
> domeny - IMO to bardzo krytyczny element srodowiska

jak najbardziej krytyczny, ale po prostu w domenie zmiany nie nastepuja
tak czesto, i zazwyczaj jest lacznosc pomiedzy serwerami.

>>> no tak - ale jeden master dla wiekszych rozwiazan nie jest
>>> rozwiazaniem - jezeli chodzi o OpenSource to mozna sie zainteresowac
>>> Fedora Directory Server chociaz to jeszcze development jest
>>
>>
>> zalezy jak definiujesz "wieksze rozwiazania".
>
>
> 15k userow rozrzuconych po 300 lokalizacjach w calym kraju

rozwiazanie na pewno duze.
ale samo logowanie / wylogowanie to naprawde maly ruch.

> kilkaset k userow rozrzuconych po kilkudziesieciu lokalizacjach na calym
> swiecie
>
> ale i mniejsze jak kilkuset userow w kilku oddzialach czy nawet jednej
> lokalizacji
>
>
>>> A OpenLDAP to przy okazji slabo wydajnosciowo w porownaniu do AD jest.
>>
>> bzdura.
>>
>> (...)
>
>
> Tak uwazasz czy wiesz. Jezeli bedzie bardzo trzeba to poszukam artykulu
> z serwer watch albo czegos takiego ktory czytalem co do porownania
> wydajnosci OpenLDAP i AD. A przyklad z zycia wziety - ejst sobie
> miedzynarodowa korporacja ktora dostarcza wiekszosc kontenerow
> przewozonych statkami na swiecie .. korzystaja z systemu pocztowego
> ktory orginalnie mial w back-end OpenLDAP, niestety ze wzrostem liczby
> userow okazalo sie ze system siada i waskim gardlem jest OpenLDAP.

tak, widzialem to w jakiejs obiektywnej inaczej "reklamie" z cyklu "Get
the Facts".

> Administrator usiadl, zastapil OpenLDAP poprzez ADAM (AD w Aplication
> Mode, te same mechanizmy co w AD ale to po prostu serwer LDAP wiec
> porwonywalny z AD), zastapil modul komunikacji z OpenLDAP oryginalny na
> lekko zmodyfikowany przez siebie i problem zostal rozwiazany, bez
> nakladow na software itp tylko naklady na wlasna prace i pomyslunek.

po prostu administrator znal sie na AD, a nie znal na OpenLDAP - co w
tym dziwnego ze specjalista od AD potrafi lepiej skonfigurowac cos, na
czym sie zna, od czegos, na czym sie nie zna?

> ADAM chodzi na tych samych maszynach na ktorych wczesniej chdozil
> OpenLDAP, z taka sama iloscia userow i nie ma problemu z wydajnoscia a
> do tego zyskali wszystko co daje wlasnie multimaster replication.
>
> Co do wynikow to zachecam do zajrzenia tutaj:
> http://www.daasi.de/staff/norbert/thesis/html/node12.html
>
> Te wyniki w odniesieniu do ADAM prawdopodobnie bylyby jeszcze lepsze bo
> ADAM to tylko LDAP serwer bez pewnych narzutow ktore posiada AD.
>
> Tutaj jest interesujace porownanie:
> http://www.terena.nl/conferences/tnc2003/programme/papers/p1d1.pdf
>
> Jak widac AD nie jest championem a patrzac na poszczegolne wyniki testow
> wychodzi ze OpenLDAP byl lepszy. Swoja droga ciekawy jest wniosek koncowy:
>
> <cytat>
> OpenLDAP 2.0.23 – Performance was extremely strong in the search tests
> we carried out but in all
> the modification type tests it was by far the worst performing directory.
> </cytat>
>
> Prawde mowiac nie zgodzilbym sie z niektorymi tezami koncowymi tego
> raportu jak na przyklad
> <cytat>
> Active Directory was the hardest to
> administer, which was surprising, as Microsoft normally provide
> reasonably good user interfaces for
> their software. In order to administer Active Directory, such as making
> changes to the schema, it was
> necessary to install separate ‘snap-ins’, giving the impression
> Microsoft do not trust most of their
> directory administrators to make simple changes.
>
> (...)
>
> In summary, all interfaces were good, with the exception of Active
> Directory, which provides a poor
> interface, and a highly awkward backup and restore.
>
> </cytat>
>
>
> Oczywiscie nie twierdze ze tak jest we wszystkich przypadkach bo opieram
> sie tylko na wynikach na ktore natrafilem w sieci .. moze czas
> przetestowac cosik i zrobic takie zestawienie.

ile testow, tyle wynikow.
przejzalem naprawde wiele testow, benchmarkow serwerow LDAP, i w
wiekszosci z nich wyniki byly albo zblizone, albo AD nieznacznie
ustepowal, albo OpenLDAP nieznacznie ustepowal. w niektorych rodzajach
testow OpenLDAP byl duzo szybszy, by w niektorych byc ciut wolniejszym.

tak wiec twoja uwaga, ze "OpenLDAP to przy okazji slabo wydajnosciowo w
porownaniu do AD jest", jest naprawde nie na miejscu.

-- 
Tomek