Skocz do zawartości

mcbarlo

Firma
  • Zawartość

    513
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    4

Posty napisane przez mcbarlo


  1. @MarekCPU tak w kwestii formalnej poczytaj o interfacie u.2. Wcale nie trzeba slotu PCI-E żeby podłączyć dysk działający z wykorzystaniem protokołu NVMe. Są rozwiązania storage'owe, które pozwalają zainstalować nawet 48 dysków NVMe w obudowie 2U.

     

    Tak na marginesie to wcale nie wiadomo czy webh korzysta w ogóle z klasycznego RAID-a. Przy usłudze typu VPS może to być rozproszony storage np. Ceph. Zapewnia to mega wydajność, skalowalność i bezpieczeństwo.


  2. Szukam sprawdzonego i dobrego wykonawcy aplikacji webowych. Zależy mi przede wszystkim na tym żeby osoba lub osoby pracujące na projektem myślały. Nie chce być beta testerem projektu, nie chce zgłaszać ciągle banalnych poprawek, nie chce sprawdzać czy jedna poprawka nie zepsuła innej.

     

    W związku z powyższym priorytetem jest jakość, a nie cena. Szukam kogoś do ciągłej współpracy. Jeśli znacie firmę godną polecenia to bardzo proszę o namiary.


  3. Jeśli relacja jest b2b to żadne prawa konsumenckie nie obowiązują. Zresztą osobiście jestem za tym żeby ludzie zwyczajnie czytali umowy i podejmowali wybory świadomie, a nie potem płakali, bo czegoś nie wiedzieli. Wszystkie prawa konsumenckie oduczają myślenia, bo ludzie naiwnie myślą, że państwo ich ochroni. Ale to już temat na inną dyskusję.

     

    Paweł P. napisał, że jest z firmą wiele lat, więc pytanie jak traktować odnowienie usługi? Czy jako nową umowę gdzie zatwierdza się od nowa regulaminy jak jest np. w Arubie czy tylko odnowienie z warunkami obowiązującymi z czasów rejestracji.


  4. Nie oceniam, nie popieram, ani nie neguje tego co opisałeś. Ale tak z drugiej strony pomyśl, że firma hostignowa też ponosi koszty z tytułu większego obciążenia serwera i łącza jak Twoje konto generuje większy ruch.

     

    Nie sądzę żeby były jakiekolwiek regulacje poza umową (regulaminem) na który się zgodziłeś podczas rejestracji usługi i potem pewnie na jego zmiany po drodze. Także to jest kwestia dogadania klienta z firmą. Ty wolisz żeby Ci zablokowali stronę, a inny woli zapłacić więcej, ale chce mieć koniecznie usługę utrzymaną online. Nie ma to nic wspólnego z etyką, bo to zależy od potrzeb. Być może jest jakiś limit przekroczenia powyżej którego nakładana jest blokada.

     

    Podobnie działają operatorzy telekomunikacyjni. Jak masz abonament i dużo wygadasz to naturalne jest, że masz większą fakturę, ale do pewnego momentu. Jak kwota osiąganie, strzelam, 1500 zł to rozmowy wychodzące zostaną zablokowane.

    • Upvote 1

  5. Jasne. Robiłem pętle, raz pomyliłem adresacje do monitorów i nieświadomy tego faktu próbowałem zreanimować storage. :) Tu faktycznie po ustawieniu wszystkiego miałem część zdegradowanych PG, ale ogarnęło się samo w kilka minut.

     

    Wyrywałem kabel z prądem ze wszystkich node'ów w jednej chwili. Tu odrazu health ok po starcie.

     

    Póki co kombinuje z różnymi konfiguracjami, psuciem na poważnie zajmę się później.


  6. Wracając do tematu pomęczyłem nieco testowy klaster na Proxmoxie 5 z Cephem. Mimo wielu prób jeszcze go nie zepsułem. :) Zastanawiam się nad rozwiązaniem sieci przy trzech node'ach. Cel jest taki żeby uniknąć dwóch drogich switchy 10G i mieć fail-over.

     

    Zrobiłem to tak, że każdy node ma 2 sieciówki dla Cepha i spiąłem je w ringu. Wszystkie te interface'y są w bridge'u OVS i żeby nie było pętli włączone jest RSTP. W zasadzie działa to sprawnie. Kiedy wypnę jakiś link to wszystko żyje. Aczkolwiek RSTP jak nie trudno się domyślić zawsze kładzie jedno połączenie przez co ruch z pierwszego do trzeciego serwera musi iść przez drugi, a to marnowanie pasma.

     

    Druga opcja to Linux Bond broadcast. Tutaj powyższy problem konieczności przechodzenia ruchu nie występuje, ale znowu nie ma fail-overa co jest niedopuszczalne.

     

    Obie metody są problematyczne podczas rozbudowy klastra.

     

    Czy według Was jest szansa żeby to skonfigurować w taki sposób żeby nie marnować przepustowości, mieć fail-over i może nawet load-balancing?


  7. Jesteś tego pewien? Seria SM to odpowiednik S3700, czyli maksymalna wytrzymałość. Współczynnik TBW ma na poziomie 6160. Seria PM ma 1366 TBW i w tym wypadku wydajność, a nie wytrzymałość jest priorytetem. Seria Pro ma 300 TBW.

     

    Jakie tam ktoś wsadził kości to nie ma znaczenia tak do końca. Można przecież zbudować wytrzymały dysk na TLC albo mało wytrzymały na MLC.

     

    Samsungi PM są rozsądnym wyborem tylko zawsze jak kupowałem dyski to nie były dostępne.


  8. Owszem, replikacja to nie backup, ale na serwerze repliki mam jeszcze kilka snapshotów z których mogę przywrócić dane do tych z danego dnia. Backup, to osobny serwer, do którego dostęp mają klienci i mogą z niego pobierać dane.

     

    Tak, mam na myśli lice migration.

     

    To co Ci opisałem nie jest 100% HA, a jedynie repliką z której momentalnie można podnieść dane w przypadku awarii storage. Lub też w razie potrzeby mogę przepiąć ruch na serwer repliki.

     

    Dyski są tanie. 1TB ~1,5k netto. Nasz serwer pod storage (bez dysków) to koszt około 20k netto, replika kolejne 20k netto. Policz ile możesz za to kupić dysków ;-), a do tych serwerów musisz jeszcze też dyski dołożyć.

     

    Jak jest live migration to musi być współdzielony storage oraz możliwość skorzystania z HA. Zależy co masz na myśli mówiąć HA. Czy podniesienie wirtualki po padzie node'a czy jej magiczne przerzucenie bez restartu. Takie rzeczy ma vmware, ale i eksperymantalnie w KVM-ie.

     

    Ten 1 TB za 1.5k netto to SSD? Co to za model, bo jakiś podejrzanie tani?


  9. Replikacji w czasie rzeczywistym nie traktuje jako backupu, ale w przypadku sprzętowego padu da bardzo szybki czas reanimacji - to fakt. Jak jakieś herezje zaczną dziać się po stronie systemu plików to one również się zreplikują i tu ważny jest backup, który odzyskuje się dłuuugo. Choć przy nie przesadzaniu w wielkością wirtualek może nie być dramatu choć niekoniecznie.

     

    Piszesz o łatwym przenoszeniu wirtualek, ale rozumiem, że nie masz na myśli live migration?

     

    HA przy swej całej za***istości jest cholernie skomplikowane co może powodować problemy, ale w końcu trzeba przeskoczyć ten level wyżej i sprawdzić to rozwiązanie w praktyce. :)

     

    Jeszcze słówko na temat wolnych dysków. Nie chce zajechać ich na 99%, ale sam pewnie wiesz, że są takie przypadki gdzie wręcz nie ma szans skorzystać z zainstalowanego storage i to jest według mnie marnowanie przestrzeni. Przy konsolidacji mogłaby zostać użyta przez inny system, a bez klastra jest to upierdliwe, a na produkcji nie możliwe (nie teoretycznie, ale praktycznie).


  10. No właśnie nie jestem do końca przekonany co do ekonomicznego uzasadnienia tej tezy choć macierz w rozumieniu klasycznym mi się w ni cholery nie zapina finansowo. Czasem nie da się dorzucić dysków na wyrost, bo serwery mają ograniczoną ilość ramek, a te co mają ich więcej są droższe. Być może na pewnym poziomie skali opłaca się stosować zróżnicowanie funkcji pełnionych przez konkretne maszyny tj. mocne serwery 1U do obliczeń + słabsze wieloramkowe na storage.

     

    Największy stres jest z przestrzenią SSD, bo jest droga choć szybko tanieje. Wówczas instalowanie przestrzeni na zaś to obarczanie usługi niepotrzebnymi kosztami. Może być nawet tak, że nigdy tch dysków nie wykorzystam, bo stwierdzę, że trzeba zamiast SATA instalować już NVMe. :)

     

    Ceph to taki złoty środek, a jako bonus daje środowisko HA co nie jest bez znaczenia. W jakich okolicznościach Ceph Ci się sypnął? Bardzo mnie to interesuje w perspektywie moich prób popsucia testowego klastra.

     

    Dodam jeszcze, że nie mam zamiaru robić pierdylion-node'owych klastrów. Myślę, że 5 serwerów na klaster daje wystarczającą elastyczność żeby skutecznie zapobiegać marnacji miejsca i takie systemu można potem powielać.


  11. Celem jest optymalizacja wykorzystania miejsca na dyskach. Mam serwery gdzie jest sporo miejsca, ale jest kiepsko z pamięcią albo procesorami, a są takie gdzie procek dłubie w nosie, a na dysku ciasno. Rozumiem, że można było to lepiej zaplanować, ale to nie jest rozwiązanie. Potrzebuje czegoś co da się lepiej skalować niż autonomiczne systemy.

     

    Rozumiem argument o straszliwych skutkach potencjalnej awarii i szczerze mówiąc właśnie on mnie zniechęca do scentralizowanych rozwiązań.

     

    Obecnie mam klaster testowy na którym badam Cepha i póki co jest moim faworytem. :)

×