Wiele maszyn JVM kontra serwer pojedynczej aplikacji

Mam do czynienia z systemem, który uruchamia aplikację Java na klienta we własnej JVM. Mamy około pół tuzina serwerów dedykowanych, które teraz mają prawie 100 JVM i zestawy niestandardowych skryptów do zarządzania tymi maszynami JVM. Ta konfiguracja naprawdę pokazuje swój wiek w tym momencie: zarządzanie, że wiele maszyn JVM staje się koszmarem monitorowania/zarządzania i ciągle mamy do czynienia z problemami z wielkością sterty. Chcielibyśmy przejść do bardziej nowoczesnego podejścia i po prostu uruchomić pakiet aplikacji na jednym serwerze aplikacji na fizyczną maszynę. Jednak oddzielenie aplikacji od siebie ma wyraźne zalety w zakresie izolacji (np. Błędy braku pamięci dotyczą tylko jednego klienta). Każdy stos oprogramowania klienta ma wymagania dotyczące pamięci, które różnią się znacznie.Wiele maszyn JVM kontra serwer pojedynczej aplikacji

Moje pytanie: czy istnieje sposób, aby mieć najlepsze cechy obu światów i uruchamiać wiele aplikacji w jednej maszynie JVM (serwer aplikacji) i nadal utrzymywać pewien poziom izolacji? A może to tylko współczesny fakt, że w dzisiejszych czasach potrzebujesz zarządzać wymaganiami pamięciowymi dla zestawu aplikacji? Czy są tu inne rozwiązania oprócz serwera aplikacji lub kontenera Java EE (np. Wildfly lub Spring), którego tu brakuje? Wygląda na to, że ten system jest zaporą z innej ery!

Źródło

2014-10-01 Noky

Nowoczesne podejście coraz częściej wykorzystuje wirtualne maszyny JVM dla aplikacji na wirtualnych hostach. Aby uzyskać pożądaną skalę, zdecydowanie sugeruję, aby w Cloud Foundry pominąć większość zarządzania, o którym mówisz. – chrylis

Podobnie jak w komentarzu Chrylis, nowoczesne podejście NIE polega na używaniu serwerów aplikacji. Wielorakość jest również martwa, ponieważ dlaczego masz kłopot z tym, kiedy możesz używać maszyn wirtualnych lub kontenerów takich jak Docker, aby dać ci prawdziwą separację? – SteveD

Myślę, że koncentrujesz się na niewłaściwym problemie: dlaczego ciągle masz problemy z wielkością sterty? Czy Twoje aplikacje przepełniają pamięć? Czy masz nieograniczoną konsumpcję pamięci? Czy twoja aplikacja nie przystosowuje się do stałego korzystania z pamięci dla danego obciążenia? – SteveD

Zamówienie JVM dla wielu dzierżawców.

IBM JRE ma go już: http://www.ibm.com/developerworks/library/j-multitenant-java/

Waratek wdrożył go w górnej części Oracle JRE i stworzyli ElastiCat, widelec Tomcat że izoluje różnych aplikacji w tym samym pojemniku: http://www.elasticat.com/faq/

multi- Podobno dzierżawa lokacji pojawia się również w oficjalnej JVM Oracle Java 9.

============================================== =========

Aktualizacja: 9 Java jest obecnie, ale żadne słowo z Oracle o multi-najmu. Wygląda na to, że wolą mieć wiele maszyn JVM w tych dniach, nawet wiele kontenerów (np. Doker).

Źródło

2014-10-01 21:41:17 greyfairer

Nie ma plusy i minusy każdej z metod:

Shared JVM

Dolna napowietrznych - zużycie pamięci JVM (podstawowe biblioteki itd.) Tylko musi być załadowany raz.
Lepsze wykorzystanie pamięci. Procesy Java będą zużywać pamięć systemową dla przestrzeni sterty, która może nie być aktualnie używana.

Oddzielna JVM

izolacji od 'chciwych' lub 'nieszczelne' aplikacji.
Lepsze zabezpieczenie przed złośliwym kodem.
Łatwiejsze aktualizacje, aktualizowanie jednej aplikacji bez wyłączania drugiej.

Ogólnie rzecz biorąc, nie ustanowiłabym ogólnej polityki. Poszukaj małych/mikro-usług lub innych aplikacji o niskim stopniu wykorzystania, które mogą być dobrymi kandydatami do pierwszego udostępnienia, a następnie rozszerzaj je.

Źródło

2014-10-01 16:10:24 Mikaveli

Dzięki Mikaveli. Zdaję sobie doskonale sprawę z tych kompromisów. To, z czym mam do czynienia, to ~ 100 wystąpień tej samej aplikacji, z których każda działa we własnej JVM (jedna instancja na klienta). Daje nam to dużą elastyczność (można uruchomić inną wersję aplikacji w zależności od klienta) i izolację (awarie aplikacji nie mają wpływu na innych klientów). Jednak to po prostu wydaje się stare i niezdarne, ból do zarządzania/monitorowania i coraz trudniej skalować. Musi być nowocześniejszy sposób radzenia sobie z tymi wdrożeniami aplikacji ... – Noky

Proponuję przenieść wszystko, co jest odpowiednie do nowoczesnego serwera aplikacji (JBoss lub Glassfish), w zależności od tego, czy są to głównie aplikacje internetowe, czy też potrzebuję trochę przeróbek. Serwer aplikacji nabiera dużego bólu związanego z zarządzaniem i monitorowaniem, więc może być wart ból związany z przejściem. – Mikaveli

Glassfish nie żyje - nie polecałbym nikogo, kto się do tego przeniesie. – SteveD

Sprawdźcie Spring Boot lub Fabric8 dla nowoczesnego spojrzenia na prowadzenie Java w rozsądny sposób

Źródło

2014-10-02 08:25:27 SteveD

Obydwie funkcje służą do tworzenia oddzielnych maszyn wirtualnych. Rozwiązujesz problemy związane z monitorowaniem/zarządzaniem, ale nadal musisz ręcznie zarządzać pamięcią. – greyfairer

Podejrzewam, że głównym problemem nie jest zarządzanie aplikacjami i ich pamięcią, ale dlaczego ta aplikacja jest tak niestabilna, że wymaga ciągłego przeglądania plików? – SteveD

Dobra rada SteveD. Problem nie polega na tym, że aplikacja jest niestabilna. To nie jest aplikacja internetowa, ale raczej duża aplikacja z wieloma różnymi niestandardowymi opcjami i dodatkami, które różnią się w zależności od potrzeb i wielkości klienta. Tak więc nie ma zestawu "jeden rozmiar pasuje do wszystkich" sposób przydzielania pamięci dla aplikacji. Mimo że aplikacja jest ogólnie dość stabilna, faktem jest, że czasami pojawiają się problemy; wyłączenie aplikacji było ogromną wygraną, gdy coś pójdzie nie tak. Umiejętność wydzielania porcji pamięci na klienta jest więc zarówno błogosławieństwem, jak i przekleństwem. – Noky

Innym ważnym powodem, aby mieć wiele JVM zamiast jednego jest w obliczu grupy NUMA. Nie możesz rozpowszechniać swoich wątków w ramach jednej grupy JVM o odpowiednich liczbach, jak w przypadku wielu procesów jvm. Przynajmniej nigdy nie znalazłem sposobu, żeby to zrobić.

Mamy tutaj maszyny z dwoma procesorami, z których każdy ma 18 rdzeni. Daje to dwie grupy numa i nie możemy wymusić 34 wątków, które zostaną rozproszone na procesorze, jeśli używana jest tylko jedna JVM. Jest to oczywiście spowodowane tym, że zakłada, że wszystkie wątki tego samego procesu JVM muszą mieć szybki dostęp do tej samej pamięci, co nie ma miejsca.

Po 34 procesach system zakłada, że nie ma potrzeby korzystania z pamięci współdzielonej, a tym samym rozłożenia ich na oba procesory.

Jeśli ktoś zna lepszy sposób na zrobienie tego, byłbym bardzo zadowolony, słysząc go.

Źródło

2017-06-06 16:19:33

Wiele maszyn JVM kontra serwer pojedynczej aplikacji

Odpowiedz

Powiązane problemy