Suspect

Polecałbym udać się do jakiejś kancelarii prawnej i wysłać do siedziby firmy oficjane wezwanie do wywiązania się z umowy pod groźbą skierowania sprawy na drogę sądową. Sąd zawsze bierze pod uwagę to czy strony próbowały polubownego załatwienia sprawy więc w takiej sytuacji pokrzywdzony jest już na lepszej pozycji. Jeżeli mimo otrzymania oficjalnego pisma firma nadal nie ma zamiaru wywiązywać się z umowy, bez wahania kierować sprawę na drogę sądową. Przecież to Wasze, ciężko zarobione pieniądze do których macie pełne prawo. Tak samo jak macie prawo do egzekwowania zapisów w umowie. Jeżeli uzyskali pieniądze od operatorów a nie przekazali ich dla swoich partnerów to ewidentnie podchodzi to pod przywłaszczenie. Operatorzy z reguły nie zalegają z płatnościami.

Tak, WAW-1 ma swój własny VAC w tym oczywiście firewall network. Korzystam z WAW-1 od początku jego istnienia. Obecnie to bardzo stabilne centrum danych nie odbiegające jakością od pozostałych oferowanych przez OVH. Mogę się pochwalić np. tym uptime 22:32:24 up 477 days Oczywiście na podstawie uptime można ocenić jedynie stabilność zasilania jednak przerw w działaniu łącza również nie odnotowuję.

Warto zapytać Twojej firmy hostingowej dlaczego korzystaja ze starszej wersji OpenVZ a nie OpenVZ 7. W przypadku tej drugiej opcji miałbyś do dyspozycji kernel 3.10.0.

Po przeczytaniu niebezpiecznika bardzo zacząłem się obawiać o wydajność jednak okazuje się, że tytuł artykułu to typowy clickbait. Sądziłem, że skoro niebezpiecznik pisze o spadku wydajności nawet o 63% to pewnie w moim przypadku będzie to jakieś 20% (zgadując). Moje obawy były na szczęście mocno przesadzone. Dziś postanowiłem zaaplikować wszystkie dostępne patche w tym nowy kernel. Postanowiłem przy tym zrobić benchmark który jak wiadomo nie odda w 100% dokładnych różnic w wydajności jednak pozwoli przybliżyć ile taka różnica wynosi. Kernel 3.10.0-514.16.1.vz7.30.10 #1 SMP Sat Apr 29 20:28:55 MSK 2017 x86_64 Test 8 wątkowy CPU speed: events per second: 9129.34 Test 1 wątkowy CPU speed: events per second: 1423.28 Kernel 3.10.0-693.11.6.vz7.40.4 #1 SMP Fri Jan 5 21:20:16 MSK 2018 x86_64 + wszystkie dostępne w repozytorium poprawki Test 8 wątkowy CPU speed: events per second: 9260.09 Test 1 wątkowy CPU speed: events per second: 1416.83 Testy przeprowadzone na 8 wątkowym procesorze Intel i7-6700K z użyciem sysbench. Wniosek: nie ma widocznego spadku wydajności procesora

Na wszystkich swoich serwerach używam Monitorix który spełnia większość moich oczekiwań. Jest niezwykle prosty w konfiguracji. Na uwagę zasługuje fakt, że jest rozwijany od ponad 12 lat. Polecam tym którzy nie mieli jeszcze okazji przetestować tego narzędzia.

Nie do końca tak jest, że sam fakt nie używania tych danych osobowych na produkcji rozwiązuje problem. A co w sytuacji gdy zajdzie potrzeba przywrócenia backupu danych? Jedyne rozsądne rozwiązanie tego problemu zostało opisane w poniższym artykule. Polecam zapoznanie się z nim i zachęcam do dalszej dyskusji dotyczącej tego rozwiązania. http://rodo2018.pl/prawo-do-bycia-zapomnianym-a-kopie-zapasowe/

Na pewno jest taka opcja w SYS? Zgadzam się jednak co do tego, że przed otrzymaniem e-maila nie działają żadne mechanizmy filtrowania ruchu. Działają jedynie sondy analizujące ruch które pozwalają na wykrywanie ataków. Aby była jasność czy blokowanie ruchu następuje przed serwerem włącz logowanie ruchu przez tcpdump na maszynie która utrzymuje serwer MySQL i sprawdź czy wszystkie inicjowane połączenia docierają do serwera czy może część z nich jest gubiona po drodze. Może być też taka sytuacja, że docierają do serwera lecz ze znacznym opóźnieniem. Wtedy też należy szukać przyczyny gdzie indziej niż sama maszyna na której działa serwer MySQL. Jest jeszcze jedna możliwość która zdarza się niezwykle rzadko. Zdarzało mi się, że otrzymywałem "wadliwe" adresy IP. Mianowicie posiadały jakieś ograniczenia w ruchu wdrażane prawdopodobnie na potrzeby ich wcześniejszego użytkownika. Powodowało to przeróżne problemy które znikały po zmianie adresu IP na inny. Taki problem miało około 3% adresów. Zdarzyło mi się nawet, że ruch na moje IP, kierowany był do dwóch różnych serwerów naprzemiennie Pomogła w tej sytuacji dopiero interwencja techniczna. Spróbuj więc przypisać do swojego serwera inny adres IP i z jego użyciem połączyć się z serwerem MySQL.

Mylisz się, przy każdym połączeniu z serwerem MySQL uzyskiwany jest rev DNS dla łączącego się IP. Można wyłączyć ten mechanizm definiując w konfiguracji parametr: skip-name-resolve Więcej informacji na ten temat: https://dev.mysql.com/doc/refman/5.7/en/host-cache.html Przykłady skutków powolnego tłumaczenia nazw przez serwer MySQL: https://stackoverflow.com/questions/1292856/why-is-connecting-to-mysql-server-so-slow

Jak duży jest ping między serwerem WWW a serwerem MySQL? Czy na którejś z maszyn zdefiniowane są ograniczenia w ruchu przez iptables? Czy sprawdzałeś szybkość działania serwera DNS z którego korzystają obydwie maszyny? Być może podstawowy jest niedostępny i korzystają z zapasowego co znacznie wydłużyłoby wszelkie żądania.

Takiej sytuacji należy unikać przez odpowiedni regulamin działu który powinien limitować ilość tematów w postaci ofert zamieszczanych przez poszczególne firmy. Może to być np. jeden temat w miesiącu na firmę lub wymuszczenie tylko i wyłączenie jednego tematu dla jednej firmy gdzie nowości byłyby dodawane jako odpowiedź. Wszystko da się odpowiednio rozwiązać.

Wątpię aby to przyniosło jakiś skutek. Marketingowcy zawsze wyznają zasadę, że trzeba reklamować wszędzie gdzie się da. Oczywiście czym innym jest skuteczność reklamy która na tym forum będzie pewnie rzędu promila

Powinniśmy tworzyć niezależne forum gdzie każdy ma prawo do wypowiedzi, niezależnie od intencji. Nazwa.pl też powinna mieć prawo do umieszczania swoich ofert a naszym prawem jest je odpowiednio komentować. Jako, że użytkownicy tego forum to głównie osoby z jakimś doświadczeniem, znaczna część komentarzy raczej nie będzie zbyt przychylna ale za to zgodna z rzeczywistością

Na forum zarejestrowano konto "nazwa.pl". Jeżeli jest oficjalne to fajnie by było gdyby ktoś się z tego wytłumaczył. Zdaję sobie jednak sprawę, że bez wszechobecnej cenzury może to być nieco trudniejsze. Wypowiedź na niezależnym forum to świetny test rzetelności firmy.

Szczegółowe informacje na temat ataków nie są dostępne, być może support udzieliłby dodatkowych informacji. Sądzę jednak, że interesowanie się źródłem nieskutecznego ataku i jego cechami to marnowanie czasu Twojego i supportu. Polecam Ci wdrożyć stałe logowanie ruchu (samych nagłówków) na swoim serwerze i jego archiwizowanie. Dzięki takiemu rozwiązaniu gdy rozpocznie się atak, szukasz odpowiedniego zrzutu ruchu i masz szczegółowe informacje na temat tego jak wyglądał atak. W zebranych przez Ciebie logach będzie oczywiście widoczna jedynie początkowa faza ataku, do czasu rozpoczęcia właściwego filtrowania.

W przypadku serwerów VPS blokowali zawsze cały ruch UDP na czas ataku, stąd może Twoja opinia, że nie działa dobrze. Chyba, że coś się w tej kwestii zmieniło.

Posiadam kilka od bardzo długiego czasu, zarówno z oferty GAME jak i pozostałych. W zwykłej ofercie SoYouStart czas reakcji jest w granicach kilku sekund. Zdarzają się jednak skuteczne ataki DDoS których system detekcji w ogóle nie wykrywa lub wykrywa po długim czasie. Mowa tu o atakach które są poniżej ich progów detekcji czyli ataki rzędu 100-200Mbps które przy kilkuset tysiącach pakietów na sekundę mogą skutecznie unieruchomić Twój serwer. W ofercie SoYouStart GAME sytuacja wygląda znacznie lepiej i to nie tylko w kwestii gier opartych na protokole UDP. W ofercie tej czas reakcji jest na poziomie kilku ms także dla ataków na protokole TCP. Oferta ta będzie więc również odpowiednia np. do ochrony strony internetowej przed atakami DDoS. Rozważ jeszcze jakiś tani serwer dedykowany z OVH, najtańszy możesz mieć za 270zł brutto / msc. W OVH miałbyś możliwość włączenia stałego filtrowania co w praktyce zadziała podobnie jak oferta GAME w SoYouStart. Będziesz też miał możliwość konfiguracji firewalla aby jeszcze lepiej chronić swój serwer. W OVH w każdej ofercie będziesz miał możliwość utworzenia RAID natomiast w SoYouStart GAME takiej możliwości nie ma ze względu na jeden dysk co dyskwalifikuje tą ofertę do przechowywania danych które trudno będzie odtworzyć. Reasumując: - Zwykłe serwery SoYouStart to czas reakcji na poziomie kilku sekund i możliwość skutecznych ataków - SoYouStart GAME to czas reakcji na poziomie kilku ms na każdy atak DDoS, nigdy nie odnotowałem w tej ofercie skutecznego ataku DDoS (poza atakami L7). Minus to jeden dysk. - Serwery z OVH to możliwość włączenia stałego filtrowania oraz skonfigurowania firewalla według swoich potrzeb. Przy stałym filtrowaniu i skonfigurowanym firewallu nigdy nie odnotowałem w tej ofercie skutecznego ataku DDoS. Dodatkowa korzyść to co najmniej 2 dyski.

OVH to bardzo dobry wybór dla firm które oczekują stabilności działania usługi i najlepszych warunków do rozwoju. Pod tym względem naprawdę trudno im dorównać w naszej rodzimej lokalizacji. Inwestują ogromne kwoty w centra danych, posiadają infrastrukturę światłowodwą o ogromnej przepustowości, zapewniają najlepszą ochronę przed atakami DDoS, darmowe adresy IP, instalacje w 120 sekund itp. Nie ma w Polsce centrum danych które mogłoby z nimi konkurować. Jedyna myśl to OVH WAW-1 Awarie zdarzają się wszędzie i w OVH z doświadczenia wiem, że ich ryzyko jest bardzo niewielkie ze względu na liczne redundancje. W oczekiwaniu na rozwiązanie problemu zawsze wiesz co się dzieje. Nie ma sytuacji, że dzwonisz do firmy i masz odpowiedź "coś się dzieje ale jeszcze nie wiemy co ani nie wiemy kiedy naprawimy". Wszystkie awarie kontrolujesz na bieżąco co od strony dużych firm jest ważnym atutem.

Oprzyj swoją infrastrukturę na balansowaniu ruchu, nie na przełączaniu się na inny VPS w razie awarii. Takie przełączanie nie zmienia Twojej sytuacji ponieważ nadal masz jeden wspólny punkt awarii który uśmierci działanie Twoich usług. Najbardziej niezawodne rozwiązanie do balansowania ruchu to round robin DNS. Jak każde rozwiązanie ma swoje wady jednak jego zalety są znacznie ponad nimi. Rozwiązanie to jest wykorzystywane do balansowania ruchu przez gigantów takich jak np. Google. https://www.youtube.com/watch?v=c7W40_bn3Ss

Najlepszą metodą monitoringu będzie query np. w php o którym już wcześniej wspomniałeś. Jeżeli obawiasz się fałszywych wyników to ustaw odpowiednio wyższy timeout a do tego 2-3 krotne powtórzenie komunikacji w przypadku braku odpowiedzi, następnie reakcja w postaci restartu serwera. Inna metoda to analiza logów serwera gry wywoływana z crona. Tworzysz sobie w systemie skrypt w bashu który szuka w logach informacji o crashu serwera. Jeżeli ją znajdzie to wykonuje restart serwera.

RAID 10 będzie dobrym rozwiązaniem o ile nie jest to macierz z bardzo dużą ilościa dysków. Trzeba mieć na uwadze to, że RAID 10 w praktyce zapewnia pełną odporność na awarię jednego dysku. Awaria drugiego dysku może skończyć się pełną utratą danych (w zależności od tego czy jest to dysk z tej samej grupy). Im więcej dysków wchodzi w skład macierzy, tym większe ryzyko, że 2 z nich odmówią posłuszeństwa w tym tym samym lub podobnym czasie.

Polecam Ci testować działanie wyrażeń regularnych poza kodem PHP. W przypadku bardziej skompikowanych wyrażeń regularnych to bardzo pomaga w określeniu ich prawidłowej składni a przy okazji przetestowania. Osobiście korzystam z https://regex101.com/ gdzie w czasie rzeczywistym możesz obserwować efekt działania wprowadzonego wyrażenia. To bardzo przyśpiesza pracę.

Czy oby na pewno dosteś 1 miesiąc? Moje serwery z SBG zostały przedłużone o 8 dni. Pewnie miałeś dłuższą niedostepność lub niezłe szczęście

Otwierał ktoś może zgłoszenie z takim wyborem pomocy i otrzymał odpowiedź od supportu we Wrocławiu? Mi się nie zdarzyło a wszystkie inne były odbierane przez nasz krajowy support.

Być może nie każdy to zauważył jednak przy zgłaszaniu awarii kluczowe jest prawidłowe opisanie zgłoszenia. Zgłaszałem na przestrzeni kilku lat kilka awarii i wybierając jako wybór pomocy "Zgłoszenie niedostępności usługi" otrzymywałem zawsze odpowiedź od supportu w języku angielskim spoza oddziału we Wrocławiu i oczywiście godziny odpowiedzi byłby całkowicie różne od godzin pracy oddziału we Wrocławiu. Interwencje w tak opisanym zgłoszeniu były względnie szybkie, nawet raz miałem okazję przetestować to po 4:00 nad ranem i wszystko przebiegło dosyć sprawnie - kości pamięci RAM wymieniono mi wtedy w około 1,5 godziny licząc od momentu otwarcia zgłoszenia.

Szczegóły dotyczące walki o przywrócenie zasilania https://twitter.com/olesovhcom