W jaki sposób dystrybuowany jest Erlang?

Question

Część A:

Erlang ma wiele sukcesów na temat uruchamiania współbieżnych agentów, np. miliony jednoczesnych czatów na Facebooku. To miliony agentów, ale oczywiście to nie jest milion procesorów w sieci. Mam problem ze znalezieniem danych o tym, jak dobrze Erlang skaluje się, gdy skalowanie jest "poziome" w sieci LAN/WAN.

Załóżmy, że mam wiele (dziesiątki tysięcy) fizycznych węzłów (z systemem Erlang na Linuksie), które muszą komunikować się i synchronizować małe, nieczęste ilości danych w sieci LAN/WAN. W którym momencie będę miał wąskie gardła komunikacyjne, nie między agentami, ale między fizycznymi węzłami? (A może to po prostu pracować, zakładając stabilną sieć?)

Część B:

rozumiem (jako początkującego Erlang, co oznacza, że ​​mogę być całkowicie błędne), że Erlang węzłów próbę wszystko połączyć i być świadomym siebie nawzajem, co skutkuje siecią punkt-punkt N^2. Zakładając, że część A nie będzie działać tylko z N = 10K, czy Erlang może być łatwo konfigurowany (przy użyciu gotowej konfiguracji lub trywialnego zestawu, nie pisząc pełnej implementacji algorytmów grupowania/routingu), aby węzły klastra można było zarządzać grupuje i trasuje wiadomości w całym systemie za pośrednictwem hierarchii grupy/grupy?

Answer 1

Powinniśmy sprecyzować, że mówimy o poziomej skalowalności fizycznych maszyn - to jedyny problem. Procesory na jednym komputerze będą obsługiwane przez jedną maszynę wirtualną, bez względu na to, jaka jest ich liczba.

węzeł = maszyna.

Na początek mogę powiedzieć, że 30-60 węzłów wydostaje się z pudełka (instalacja OTP wanilii) z dowolną aplikacją napisaną na górze (w Erlang). Dowód: ejabberd.

~ 100-150 jest możliwe dzięki zoptymalizowanej aplikacji niestandardowej. Chodzi mi o to, że musi to być dobry kod, napisany z wiedzą o GC, charakterystycznym typie danych, przekazywaniu wiadomości itp.

powyżej +150 jest w porządku, ale gdy mówimy o liczbach takich jak 300, 500 będzie wymagać optymalizacji & dostosowywanie warstwy TCP. Ponadto nasza aplikacja musi być świadoma kosztu np. synchronizować połączenia w klastrze.

Drugą rzeczą jest warstwa DB. Mnesia (wbudowana) ze względu na swoje funkcje nie będzie działać ponad 20 węzłów (moje doświadczenie - może się mylę). Rozwiązanie: po prostu użyj czegoś innego: dynamo DB, oddzielne klastry MySQL, HBase itp.

Najbardziej rozpowszechnioną techniką zwiększania kosztów tworzenia wysokiej jakości aplikacji i skalowalności są federacje z klastrami ~ 20-50 węzłów. Tak więc wewnętrznie jest to wydajna siatka ~ 50 erlang węzłów i jest połączona przez dowolny odpowiedni protokół z N kolejnych 50 węzłów klastrów. Podsumowując, taki system jest federacją N erlangowych klastrów.

Rozproszona erlanga jest zaprojektowana do pracy w jednym centrum danych. Jeśli potrzebujesz więcej geograficznie odległych węzłów, użyj federacji.

Istnieje wiele opcji konfiguracyjnych, np. które nie łączą ze sobą wszystkich węzłów. Może to być pomocne, jednak w ~ 50 skupieniu erlang narzut nie jest znaczący. Możesz również utworzyć wykres węzłów erlang za pomocą połączenia "ukrytego", które nie łączy się z pełną siatką, ale także nie może korzystać z połączenia ze wszystkimi węzłami.

Największy problem, jaki widzę w tego rodzaju systemach, polega na zaprojektowaniu go jako systemu bezkompatybilnego. Jeśli tego nie potrzebujesz, wszystko powinno być w porządku.