gb1

@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.

Zatem wąskim gardłem były dyski, nie kontrolery w tym przpadku. Pamięć jest zawodna, te dyski nie mają nawet możliwości zbliżyć się do takich wyników. Należy stać na baczność natomiast w innych sytuacjach. Awarie i wymiana dysków to standardowa czynność obsługowa, w naszym przypadku nie wymagająca nawet udziału administratora.

Z ciekawości zapytam o producenta i model ? Rozumiem że badania / testy dokonywałeś na takim samym nośnikach, zatem ciekawe jest jakie wykorzystałeś nośniki (producent i model) oraz jakie środowisko testowe. Módl się do swojego Anioła Stróża bardzo mocno :-) awarie były, są i będą, wszystko kwestią jedynie jak jesteśmy na nie przygotowani. To że wypadną to nie jest większym problemem, problem jak dwa w tej samej grupie (nie jakiejkolwiek dwa) nieodwracalnie ulegną awarii bez możliwości odczytu danych. Obecnym kierunkiem dla "capacity" to SDS zatem raid w postaci jaką od lat znamy pozostaje nam jedynie w kwestiach "performance" na chwilę obecną.

W biznesie hostingu / chmury iaas element ludzki jest najdroższym składnikiem, natomiast wymagasz aby w podanej cenie dostęp do tego cennego zasobu był bezpośredni i zapewne nieograniczony (tutaj brak danych z Twojej strony). Zastanów się zatem czy stawiając takie wymaganie nie ograniczasz sobie znacząco ilości dostawców usług, a w przypadku jeśli otrzymasz takie oferty to sugerowałbym mocno zastanowić się czy to co otrzymujesz jest rzeczywiście tym czego oczekujesz. Zastanawiam się czy wymieniony wymóg jest spowodowany dotychczasowym złym doświadczeniem z dostawcą czy może brakiem doświadczenia i wiedzy który chcesz aby dostawca uzupełniał w cenie hostingu ?

Należy pamiętać że nie wszystkie kontrolery potrafią zostać przełączone bezpośrednio w HBA mode, wszystko zależy od architektury kontrolera. Znasz kontroler sprzętowy który jest znacznie bardziej wydajny aniżeli software raid przy zastosowaniu niezbyt starego sprzętu ? Wszystko zależy od zastosowania i oczekiwań. Jak trafnie @Malu zauważył istotny jest także aspekt DR, zatem najlepiej dobrać rozwiązanie do własnych potrzeb i środowiska w którym całość będzie działała. Mogę Tobie podpowiedzieć że rozsądnym rozwiązaniem są dyski SSD (min. prędkość zapisu sustained 100% na poziomie >100k iops) podłączone za pomocą SAS, umieszczone w zewnętrznych półkach, podłączone jednocześnie do dwóch serwerów fizycznych z kontrolerami LSI SAS 3308 działającymi w IT mode i software raid-10. Jednak czy to jest odpowiednie rozwiązanie do Twoich potrzeb i Twojego środowiska (sprzętowego, organizacyjnego, zasobów ludzkich) ?

@Tomek a czego chcesz się tutaj doszukiwać ? przecież to prosty HBA w trybie IT, o IR nie będę wspominał ponieważ to jakaś namiastka czegoś takiego o czym nie warto wspominać.

Co rozsądnego w ostatnim czasie produkowanego nie obsługuje dla SATA komendy TRIM czy dla UNMAP dla SAS ?

To taka podstawowa ilość, a nie większa :-) ale punkt widzenia zależy od punktu siedzenia :-) Tutaj istotna informacja, jednak powstaje pytanie czy obecne rozwiązanie jest tak kiepskie wydajnościowo czy po prostu potrzebujesz rozwiązania idącego w kierunku "performance". Jakie założenia wydajnościowe ? Jeśli wydajność jest istotna to spoglądaj w kierunku raid-10. Tak jak to wcześniej wspomniał @mcbarlo sprzętowe rozwiązania wspierające macierze idą powoli w zapomnienie w formie jaką znamy dotychczas. Możliwe że procesory z zintegrowanym FPGA oraz rozwiązania typu SmartSSD zmienią obecne trendy. Sama marka LSI nic nie mówi, istotne jest na jakim chipsecie oparty jest ten kontroler w szczególności że chcesz go wykorzystać wraz z dyskami ssd. Istotne jak wykorzystujemy kontroler i jak wystawia dysk. Na marginesie TRIM to cześć protokołu ATA czyli dotyczy tylko dysków SATA, jednak podobna funkcjonalność w przypadku SAS / NVMe także jest istotna jednak inaczej się nazywa: unmap / deallocate. Z ciekawości zapytam, według Ciebie czego mu brakuje ? Na marginesie jedynie należy dodać że ZFS to znany jest z Solarisa od Suna, a obecnie Oracla. trochę ? jestem zdania że jeszcze sporo :-) ale RedHat mocno nad tym pracuje :-) Jeśli jednak spojrzeć jak to wyglądało na początku za czasów Dreamhosta to jest nieźle :-)

@theqkash pytanie było bardziej ogólne aniżeli dotyczące wymienionego dostawcy. Pytanie dotyczy Twoich oczekiwań ;-)

@theqkash Jakiej stałej promocji byś oczekiwał ? ;-) Natomiast samo słowo promocja zwykle ma odbiór jako coś tymczasowego i okazjonalnego.