gb1

@mariaczi czystą ciekawością :-) choć także chęcią zweryfikowania lub potwierdzenia posiadanej wiedzy na temat tego segmentu rynku :-) Jaki według Ciebie poziom iops byłby dla takiej usługi odpowiedni ? Osobiście uważam że oferta jest ciekawa dla segmentu rynku do którego jest kierowana. Jedynie jej "wykonanie" jest niezwykle kiepskie co powoduje, że przestaje być interesująca do rzeczywistego zastosowania.

hmmm... ciekawe podejście, imho mało konstruktywne w dyskusji, ale jak widać podyktowane jedynie aspektem finansowym. Ja jedynie z ciekawości chciałem poznać Twoje zdanie ;-)

Tak aby struktury danych odpowiadały całości aplikacji. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Torvalds, Linus (2006-06-27)

@Archi zgadzam się z Tobą jednak bierzesz pod uwagę monolityczne aplikacje, trudno aby bardziej złożone aplikacje o architekturze rozproszonej się w taki sposób zachowywały Tak powinno być, jednak życie pokazuje że teoria znacznie różni się od praktyki :-)

Według Ciebie jaki poziom limitu iops byłby rozsądny ?

Według mnie gorsze jest to że dostawca nie udostępnia informacji o zużyciu limitu dziennego, użytkownik usługi dowiaduje się o wykorzystaniu limitu po wyłączeniu serwera. bardziej to jak tanio kupić udział w jeżdżeniu autem sportowym przez kilka godzin w miesiącu, a w pozostałym czasie zwykłym. Należy jednak pamiętać że to jest usługa kierowana do segmentu "lubię mieć możliwości" czyli usługa za przystępną cenę umożliwiająca posiadanie możliwości, oraz korzystanie z niej tylko przez ograniczony okres czasu, ponieważ przez większość nie ma potrzeby jej wykorzystywać. W usługach typu AWS, Azure czy GCE zasób dyskowy z gwarancją wykonania 10k iops kosztuje kilkaset razy więcej.

Rozwiązania widzę dwa: throttling - czyli ograniczenie parametrów lub płatność za wykorzystanie ;-) który bardziej przemawia do Twojego zastosowania ? Czy widzisz inne rozwiązania ?

Według Ciebie jak rozwiązane limity byłby rozsądne ?

Wszystko zależy od architektury aplikacji, jeśli składa się z licznych komponentów w formie subsystemów, mikroserwisów lub podobnych to część odpowiedzialna za otwarty socket jest tylko gatewayem, zatem jeśli inny komponent zwraca błąd lub jest "crashed" nie oznacza że musi zwolnić socket. Dobrym przykładem jest serwer http (np. apache lub nginx) i serwer aplikacji php działający osobno (w formie fpm lub podobnej). Błąd aplikacji lub serwera aplikacyjnego nie oznacza w takim przypadku konieczności zwolnienia socketu. Jednak coś czuję że to jest jednak aplikacja monolityczna :-)

@likufanele pod względem prawnym musi nastąpić cesja praw i obowiązków do domeny i nowy właściciel musi posiadać odpowiednią reprezentację przez rejestratora przed NASK. Wszelkie inne czynności są jedynie czynnościami technicznymi i nie powodują realnego przeniesienia praw do domeny.

@magician przecież się staram dzielić, choć może oczekujesz jedynie rozwiązań technicznych, ale według mnie aby zacząć dobierać środki techniczne wpierw należy dobrać założenia biznesowe. Widziałem za dużo przekombinowanych środowisk które po pierwsze nie spełniały wymogów HA jako całość, po drugie przez nie odpowiedni dobór środków technicznych do zamiarów (przerost formy nad treścią) powodowały same w sobie większość problemów. Podsumowując zacznij od: 1. realne założenia dla parametrów RTO oraz RPO 2. wielkość danych które podlegają ochronie oraz ich delta dzienna (jeśli są to różne obszary danych to z podziałem na grupy)

@magician z całym szacunkiem, czy jesteś pewien że z obecną wiedzą jesteś w stanie zrealizować tak ambitny duży projekt ? Sugerowałbym dołączenie do zespołu przynajmniej konsultanta z wiedzą ekspercką w tym zakresie. Jednak ja bym zaczął od ponownej oceny czy podawane parametry RTO oraz RPO są realnie wymagane dla tego projektu. Duże popularne serwisy internetowe często nie posiadają takich wymagań jakie podajesz.

@MateuszCODE ja bym nie szedł w kierunku monitorowania otwartego socketu, a na bazie tego co pisałeś bardziej w monitorowanie aplikacji przez otwarty socket. Czyli wysłania zapytania do aplikacji przez sieć, otrzymanie odpowiedzi, podjęcie decyzji co dalej zrobić na tej bazie, odczekanie wyznaczonego czasu i ponownie od początku. Jak sam napisałeś w przypadku "crash" process nadal działa i w takiej sytuacji zapewne także socket nadal jest otwarty wiec monitorowanie samego socketu nic Tobie nie wniesie.

Po pierwszy czy rzeczywiście potrzebujesz RTO i RPO o takiej samej wartości ? Czy tak niskie parametry RTP i RPO są dla Ciebie rzeczywiście istotne ? Wymienione parametry znacząco potrafią zmienić podejście i technologie które wykorzystasz. Czy chcesz podejść do tego typowo biznesowo czy hobbystycznie z założenia "nie potrzebuję ale lubię mieć możliwości" ? W zależności od konfiguracji oraz sytuacji utraty danych w proponowanym rozwiązaniu jest jak najbardziej możliwia. Pamiętajmy o tym jak dane są synchronizowane pomiędzy master i slave. @Mion dobrze radzi zastanowić się nad innym mechanizmem aniżeli baza do trzymania sesji. Pytanie czy jest realna potrzeba klastra ? Co się stanie jak utracimy sesje ? Czy sesje są tak bardzo istotne w tym rozwiązaniu że muszą być tak chronione ? Istotne jest czy celem jest niezawodność i ciągłość działania (tak rozumiem OP), a nie wydajność. Load balancery możesz także uruchomić w HA, pytanie czy masz rzeczywistą potrzebę ? Będziemy to wiedzieli jak poznamy realne biznesowe założenia dla parametrów RTO oraz RPO. Innym istotnym elementem przy planowaniu tego typu rozwiązań jest ilość danych które podlegają ochronie oraz jaka jest ich delta dzienna.

@The I usuwając miałeś świadomość co usuwasz zatem teraz wykaż się trochę większą inicjatywą we własnym zakresie, jak czekasz na pomoc innych. Myślę, że to będzie miało dobre efekty długoterminowo w zakresie powiększenia posiadanej wiedzy.

a potrafisz ładny bash napisać ? ;-) Należy jednak przyznać że rozwiązanie @Archi choć "toporne" to jedyne rozsądne. @MateuszCODE zakłąda monitorowanie portu tcp/udp, tak jak w przypadku tcp nie ma większego problemu, tak w przypadku udp nie jest to takie banalne :-) Choć jak rozwiązanie przedstawione przez @Archi wskazuje jeśli monitorujemy z tego samego systemu na którym socket jest otwarty to jest to znacznie prostsze. Natomiast wygląda na to że @MateuszCODE nie planuje monitorować portu udp, a jedynie usługę która jest udostępniona na tym porcie, a to znacząco upraszcza zadanie :-) Najwygodniej prosty skrypt w pętli wysyłający request po UDP, czekający na odpowiedź, sprawdzający zawartość po czym czekający "n" czasu do kolejnej próby. Jeśli natomiast monitorując z tego samego hosta jak sugeruje @Archi to ja bym bardziej szedł w kierunku: sudo lsof -Pi UDP:53

@The I poczytaj zatem co usunąłeś, do czego służyło, dlaczego przyrastało. Wszystko nagle stanie się jasne Innym rozwiązaniem jest wynajęcie eksperta w zakresie mongodb, który nie dość że naprawi to omówi z Tobą co się wydarzyło, co jest tego powodem i jak można postępować w przyszłości. Zatem jak widać dwie drogi nabycia wiedzy do wyboru w zależności od Twojej obecnej wiedzy i chęci do poświęcenia dłuższego czasu w celu nauki samodzielnej lub skorzystania z wiedzy eksperckiej, która jednak zwykle kosztuje.

@The I z ciekawości zapytam, usuwając miałeś świadomość co usuwasz czy to tak na zasadzie "jakoś to będzie" ? ;-)

@magician rozpocznij analizę od ustalenia dwóch bardzo podstawowych wartości RTO oraz RPO, po ich ustaleniu można zacząć dalsze planowanie.

@MateuszCODE z ciekawości zapytam jak chcesz monitorować port UDP ?

@ziemowitg ja to mało obiektywny jestem :-)

Sprawa zupełnie nie dla BOK czy administratora bym bardziej :-) to jest czysta warstwa biznesowa, czyli przed zawarciem umowy piszesz z propozycją do firmy, jeśli są zainteresowani to kontakt jest poza standardową procedurą obsługi usług hostingu. Kwestie księgowe to później możliwe także poprzez tickety, z doświadczenia podpowiem że ważne żeby przed zapłatą kwestia była uzgodniona.

@ziemowitg w jaki sposób kontakt telefoniczny zatem byłby tutaj korzystniejszy od wnoszenia opłat elektronicznie lub tradycyjnym przelewem i pobierania dokumentów księgowych (np. faktur) przez panel ? Jakieś szczególne prawa i wymagania w zakresie rozliczeń ? Możesz podać jakieś przykłady ?

@ziemowitg to teraz pytanie w jakim celu zwykle masz konieczność kontaktu z BOK, że wymagany jest kontakt telefoniczny ?

Bo to złe dyski są :-) w innych słowach mało wydajne, parametry z data sheet to jedynie zgodnie z datasheet jedynie "out of the box" czyli bez pre-conditioningu. Nie widzę możliwości jak byłby w stanie osiągnąć podawane przez Ciebie wyniki na trzech dyskach. Jestem przekonany, że w Twoim przypadku to dyski były wąskim gardłem lub coś powyżej sprzętu.