Zarzaądzanie sporą ilością serwerów

[Gość patrys]

Jak chcesz ogarnąć tą chmurę która musi mieć tonę ramu i cpu bez macierzy dyskowych ?

Niestety dalej potrzebne jest oprogramowanie które będzie komunikować się z tymi maszynami wirtualnymi i rozrzucać na nie ruch.

 

[elcct 159]

Bzdury troche, większość dużych stron nawet by poszła na jednym dedyku z SSD + cdn (czyt. szrot z reverse proxy)

 

Cloud w ogóle nie ma racji bytu, chyba tylko dla właścicieli aby naciągnąć na kase nieświadome osoby.

[Tiktalik.com 18]

Patrys,

 

owszem, potrzebny 'jakis' loadbalancer, nie bardzo wiemy natomiast jakim protokolem sie porozumiewaja, o ktorej warstwie mowimy itd.

@elcct: oprocz IO, potrzebne jest CPU..

[elcct 159]

@elcct: oprocz IO, potrzebne jest CPU..

 

Obecne CPU z dolnej półki są w stanie bez problemu obsłużyć kilkadziesiąt milionów odsłon miesięcznie nawet na php. Ale jak ktoś nie zainwestuje w programistów tylko "w chmurę", to potem się dziwi, że mu strona wolno działa... a koszty rosną niepotrzebnie

[Tiktalik.com 18]

No to moze bardziej konkretnie:

 

a) serwery dedykowane / wlasne oprogramowanie.

Nalezy napisac oprogramowanie, ktore:

- instalowalo bedzie potrzebne programy na serwerach dedykowanych

- przetrzymywalo 'lokalizacje' klienta (ktory klient na jakim serwerze)

- loadbalancowalo ruchem przychodzacym, by klient trafial na swoj serwer

 

Zarzadzanie sprzetem:

 

Nalezy zadbac o rozsadne dokupowanie serwerow, wymiane czesci w serwerach i zadbac o przywracanie danych, backupy itd.

Nie kupowac za duzo serwerow, jednak jak rosnie ruch moc szybko dokupic serwerwy dedykowane by sprostac zapotrzebowaniu

 

b) chmura / wlasne oprogramowanie loadbalansujace

Nalezy napisac oprogramowanie, ktore:

- uruchomi kolejny serwer za pomoca API dostawcy chmury

- utrzymywac informacje ktory klient na jakim serwerze

- loadbalansowac klientow pomiedzy serwerami

 

Mozna miec obraz z zainstalowanym calym oprogramowaniem per serwer i odpalac kolejne ich instancje wykorzystujac API - prosta sprawa

 

Zarzadzanie Sprzetem:

Nie trzeba angazowac kapitalu w serwery dedykowane na dluzszy okres, mozna elastycznie wlaczac/wylaczac serwery oszczedzajac czas i gotowke.

 

Podsumowanie:

 

w obu rozwiazaniach nalezy zajac sie wlasnorecznie loadabalancerem, zarzadzanie oprogramowaniem i maszynami w chmurze jest 10 x latwiejsze, czas reakcji na obciazenie / popyt w chmurze krotszy

 

Jesli chcialbys pomocy przy takim projekcie jestesmy w stanie nawet stworzyc oprogramowanie do zarzadzania takim oprogramowaniem na naszej infrastrukturze, odezwij sie na kontakt@tiktalik.com

 

pozdrawiam,

 

Daniel

[Gość patrys]

w obu rozwiazaniach nalezy zajac sie wlasnorecznie loadabalancerem, zarzadzanie oprogramowaniem i maszynami w chmurze jest 10 x latwiejsze, czas reakcji na obciazenie / popyt w chmurze krotszy

Nie przesadzajcie z marketingiem

Jedyny plus to instalacja via api i brak problemów sprzętowych.

Jednak instalacje via API można zastąpić instalacja za pomocą instalatorów wrzuconych przez SSH.

A problemy sprzętowe to już monitoring i wspominany loadbalancing, który fakt faktem musi być w chmurze.

 

Wasza chmura też ma minusy znajduje się w obrębie jednego centrum danych gdy ono ulegnie awarii z przyczyn losowych wszystko nie działa

[Kszysiu 136]

 

Jedyny plus to instalacja via api i brak problemów sprzętowych.

Czy nie lepiej dopłacić te kilka procent i nie obawiać się żadnych problemów sprzętowych? Nie musisz co jakiś czas sprawdzać jak czują się dyski, nie musisz użerać się z wszelkimi problemami typu: padł ram, padł procesor, padła sieciówka. Śpisz spokojnie (może spokojniej - bo wciąż może być coś uwalone z konfiguracją).

Jednak instalacje via API można zastąpić instalacja za pomocą instalatorów wrzuconych przez SSH.

A skonfigurujesz automatyczne zakupienie kolejnego dedyka w momencie ostrego przeciążenia? Jeśli twoja strona dostanie "efektu wykopu" to automatycznie dostawi się kolejna skonfigurowana wirtualka - a jak obciążenie się zmniejszy to zniknie.
W takiej sytuacji kupiłbyś kolejnego dedyka nie wiedząc czy w ogóle potrzebny będzie za kilka dni?

[Gość patrys]

Jasne, ale możesz to monitorować, napisać automaty przełączające i stworzyć niezłe magie.

Zyskujesz przy tym szybsze procesory, bo z tego co widziałem tikitalk ma xeony e3, lepsze I/O i więcej ramu tu jest maksymalnie 15GB.

 

Efekty wykopu to stare historie, na dobrze skonfigurowanych środowiskach widzisz ile potrafi przyjąć ruchu i tak samo je skalujesz wcześniej.

[elcct 159]

Czyli w tym przypadku straszenie awariami, "babysittingiem" serwera. Serwera i tak trzeba doglądać, nie ważne czy chmura, czy vps czy co innego, a sprzęt nie jest tak awaryjny jak kiedyś - chyba, że ulokowany w kiepskim DC, bez odpowiedniego chłodzenia itd. to możliwe nadal. Z tym, że tak samo możliwe w przypadku chmury. Już ostatnio było parę przypadków, że te niezawodne chmury okazały się tylko marketingowym bełkotem i nie zapewniają nawet w części bezpieczeństwa jakie zapewniają serwery dedykowane.

 

Inna sprawa, że jeżeli nawet do skomplikowanej strony potrzebujesz load balancera, to albo projekt tworzyli kiepscy programiści, albo oferta jest na sprzęcie z poprzedniej epoki...

Być może na "chmurę" ładuje się tyle klientów, że normalna instancja nie da rady pociągnąć trafficu i trzeba się bawić dodatkowo w load balancery.

 

 

[Pan Kot 1535]

Powiedz to serwerowni facebooka .

 

Sprawa jest prosta. Chmura głównie została stworzona jako skalowalność, w rzeczywistości mamy tu podobne bezpieczeństwo, jakie można zrobić na dedyku. O ile owszem do dedyka nie dodamy w jednej chwili parametrów to wciąż jest to prawdopodobnie najlepsze rozwiązanie na długotrwałe projekty. Wiesz dokładnie na czym stoisz, a jakikolwiek "wykop effect" o ile tworzy trochę kontrolowanego DDoS'a to nie jest czymś, z czym dedyki mogłyby sobie nie poradzić. No chyba, że rzeczywiście mamy stronę na drupalu, w której cpu podskakuje do 100% przy 2 requestach.

Edytowano Kwiecień 15, 2013 przez Archi (zobacz historię edycji)

[beliq 442]

Wasza chmura też ma minusy znajduje się w obrębie jednego centrum danych gdy ono ulegnie awarii z przyczyn losowych wszystko nie działa

 

Ich oferta mi się wyjątkowo nie podoba(*), ale... IMHO czepiasz się bez sensu,

gdyż nie istnieje sensowna replikacja via WAN odporna na BGP z zachowaniem wydajności macierzy.

 

* - strona mi się podoba, bo jest ultra przejrzysta

[Gość]

Mi się nie podoba, że w wypowiedziach nie używają polskich liter : )

 

[Tiktalik.com 18]

Moim zdaniem chmura dzialajaca w modelu IaaS, czyli dostarczyciel infrastruktury, daje klientowi elastycznosc, latwosc zarzadzania.

Ci, ktorzy nie mieli do czynienia z wiekszymi systemami czesto nie zdaja sobie sprawy z tego jak sprawy sie komplikuja, jesli serwerow jest wiecej.

 

Jesli chodzi o bezpieczenstwo, to jest ono takie, jak zarzadzi nim klient.

 

@beliq: co dokladnie Ci sie nie podoba, zalezy nam na feedbacku od potencjalnych klientow. Jesli nie chcesz nas linczowac publicznie, moze byc na priva.

 

Daniel

[elcct 159]

Powiedz to serwerowni facebooka .

 

Pisałem głównie o średniej skali projektach, coś jak Facebook to oczywiście inna klasa rozwiązań, własne DC itd.

[Tiktalik.com 18]

Inna sprawa, że jeżeli nawet do skomplikowanej strony potrzebujesz load balancera, to albo projekt tworzyli kiepscy programiści, albo oferta jest na sprzęcie z poprzedniej epoki...

Być może na "chmurę" ładuje się tyle klientów, że normalna instancja nie da rady pociągnąć trafficu i trzeba się bawić dodatkowo w load balancery.

 

Nie rozumiem, twierdzisz, ze prawidlowo wykonana strona zawsze bedzie w stanie udzwignac load na pojedynczym serwerze i ze uzycie load balancera to cos zlego? Skad takie zalozenia?

 

Moim zdaniem podzielenie serwisy nawet intencjonalnie na kilka mniejszych instancji, to dobra praktyka.

 

To ciekawa dyskusja architektoniczna.

[elcct 159]

Nie rozumiem, twierdzisz, ze prawidlowo wykonana strona zawsze bedzie w stanie udzwignac load na pojedynczym serwerze i ze uzycie load balancera to cos zlego? Skad takie zalozenia?

 

Moim zdaniem podzielenie serwisy nawet intencjonalnie na kilka mniejszych instancji, to dobra praktyka.

 

To ciekawa dyskusja architektoniczna.

 

Średnie serwisy do 100 milionów odsłon miesięcznie, bez problemu powinny działać na średniej klasy dedyku np. z E3 i SSD.

 

Wprowadzanie kolejnych instancji wprowadza tylko niepotrzebny narzut i dodatkowe punkty możliwości wystąpienia awarii (np. zamiast jednej lokalizacji trzeba monitorować kilka) oraz i tak trzeba przygotować zapasowe środowisko na wypadek awarii chociażby macierzy.

 

Oczywiście w przypadku jednego serwera, gdy coś przestanie działać np. dysk, serwis będzie offline, ale temu też można łatwo przeciwdziałać.

 

Poprzez np. replikację danych na mniejszy serwer dedykowany (nawet uruchomiony w trybie tylko do odczytu - podobne rozwiązanie stosuje Reddit), który mógłby tymczasowo przejąć rolę głównego serwera.

 

Taki system jest prosty, tani w utrzymaniu i jasny do rozliczenia.

 

Podobne rozwiązania "na chmurze" kosztują kilkukrotnie więcej i komplikują od rozliczeń (nie spotkałem się jeszcze z jasnym i klarownym cennikiem usługi), po zarządzanie.

[Pan Kot 1535]

Generalnie ja głównie widzę chmurę w jeden sposób. Jako tymczasowe rozwiązanie "out of the box" np. w przypadku awarii dedyka lub gdy potrzebujemy czegoś rzeczywiście strasznie elastycznego i umiemy tą elastyczność wykorzystać. Innym atutem jest infrastruktura, ale chmura to też serwery. Kwestia prawidłowego rozwiązania problemu.

 

Również nie pakowałbym się w chmurę w przypadku większego projektu. Ba, mam aktualnie takie dwa średnio-duże projekty, które mają przynajmniej kilka serwerów i muszę przyznać, że mam do tego większe zaufanie niż do takiej "chmury" . Ale to tylko moje odczucia.

[Tiktalik.com 18]

Panowie,

 

dostawca IaaS daje wam w zasadzie to samo, co dedyki + latwosc wlaczania/wylaczania, robienia backupow, przywracania starych obrazow, klonowania systemow itd.

 

Odnosnie 'wrzucmy wszystko na jeden serwer':

 

@elcct:

 

Przyzwyczajeni jestesmy do wiekszych serwisow niz 100mln PV/mc, ale dobrze, policzmy troche: Niech to bedzie serwis, ktory ma 90 000 000 odslon miesiecznie. 3 000 000 odslon dziennie, zalozmy, ze cos sie tam dzieje w ciagu 16 godzin na dobe, czyli mamy 52 zapytania na sekunde.

 

Jesli aplikacja jest dobrze napisana, nie ma dlugich zapytan, moze ja udzwignac e3, z wieksza iloscia ramu i szybkim dyskiem SSD.

 

Mamy jednak w takim modelu nastepujace problemy:

- awaria serwera wylacza nam serwis

- nie mamy latwej drogi do zwiekszenia wydajnosci serwisu, powiedzmy 4 krotnie.

- nie ma metody na latwe 'stageowanie' zmian i testowanie nowych wersji serwisu bez destabilizacji calosci

 

Mozna wiec podejs do tematu w nastepujacy sposob, typowa tiered architecture:

- dzielimy serwis na front endy (serwery WWW, gdzie chodzi aplikacja + cache)

- serwery bazy danych

 

Zamiast jednego serwera dedykowanego, mozemy wlaczyc np 3-4 male serwery WWW (tak by awaria ktoregos z nich nie powodowala problemow serwisu), oraz 1 badz 2 serwery bazy danych (jesli chcemy wieksza dostepnosc, master-slave).

 

mamy dzieki temu:

- wysoka dostepnosc serwisu (awaria ktorejkolwiek z maszyn wirtualnych nie prowadzi do przestojow w dzialaniu serwisu)

- latwosc skalowania - dodajac kolejne maszyny frontendowe badz slave'y bazy danych skalujemy sie horyzontalnie, powiekszajac instancje kazdej z nich wertykalnie

- latwosc stageowania/testowania zmian - nowy kod mozna deployowac na jednej z maszyn WWW nie wplywajac na dzialanie pozostalych

- sypiamy spokojniej, bo przy awarii nie trzeba biegac jak oszalaly czekajac az support cos tam podniesie, zwiekszenie ruchu obslugujemy dodajac klony maszyn frontendowych

 

Koszt w przyblizeniu wychodzi nam podobny jak w rozwiazaniu dedykowanym. Np 5 x 100 ~ 500 PLN

 

 

 

 

[theONE 526]

Podstawowa różnica pomiędzy IaaS a dedykami to cena. Rozwiązanie na IaaS kosztuje zwykle 3-4 razy tyle co rozwiązanie na dedykach. IaaS jest prostszy i uboższy, dla użytkownika.

 

Do tego użytkownik musi wykazać się:

- pełnym zaufaniem do dostarczyciela usługi co do dostępnej, wykorzystywanej i bilingowanej mocy obliczeniowej

- pełnym zaufaniem do dostarczyciela usługi co do jego zabezpieczeń

- pełnym zaufaniem do dostarczyciela usługi co do jego zdolności odpierania ataków (chyba dzisiaj kolejna zachodnia chmura miała pełen wypływ danych)

a i tak:

- awaria chmury odłącza serwis (i praktyka pokazuje że trwa dłużej niż awaria dedyka)

 

Awaryjność sprzętowa jeżeli rozpatrujemy pad serwera uniemożliwiający prace a pad chmury uniemożliwiający prace jest podobna, w przypadku awarii pojedynczego serwera nie ma wąskiego gardła u operatora w postaci zbyt małej ilości ludzi do zajęcia się sprawą

 

Podzielić serwis na fron i back i tak w pewnym momencie trzeba ze względów bezpieczeństwa a nie wydajnościowych.

 

Do tego nowe wersje serwisu nie testuje się na produkcji a na wydzielonym środowisku i tutaj chmura jest lepszym rozwiązaniem na chwilowe testy niż osobny serwer

 

Dwa serwery które zapewnią nam redundancję nadal są tańsze niż chmura, więcej jeżeli mamy drogie serwery (tzn 2x mocny procek + dużo ramu + mocne dyski) to mogę każdemu chętnemu stworzyć rozwiązanie na bazie dwóch DC, każda maszyna w jednym DC + routing + LB + przepięcie całego ruchu na jedno DC w przypadku awarii i rozwiązanie będzie tańsze niż rodzime chmury a do tego bardziej niezawodne od pojedynczego DC

 

Prywatna chmura tylko dla jednej firmy jest rozwiązaniem które bardzo mi się podoba (mam wtedy kontrole nad wszystkim) ale współdzielone chmury są zbyt skomplikowane, a przez to kosztowne i podatne na awarie oraz błędy.

 

Co się dzieje w przypadku zaniku zasilania w DC, jeżeli masz serwer dedykowany padnie, jeżeli masz chmure padnie. Po przywróceniu zasilania przy odrobinie szczęścia i odpowiednich przygotowań wczesniej twój serwer dedykowany wstanie bez problemu, chmura jeżeli dostawca nie zrobil czegoś straszie głupiego przy odrobinie szęścia też wstanie. Różnica jest w czasie przeliczania danych po padzie na dyskach, dla dedyka sprawdzenie systemu plików potrwa kilka/kilkanaście minut dla chmury gdzie storage jest wspólny, gęściej upakowany i do tego gigantyczny potrwa dłużej

[elcct 159]

(...)

 

Lepiej bym tego nie napisał

[Tiktalik.com 18]

Proponuje zaczac uzywac okreslenia IaaS, poniewaz 'chmura' jest pojeciem rozmytym, niektorzy moga udowadniac, ze serwery dedykowane to tez chmura, nie chce tutaj wchodzic w jakies flame wars, uzywajmy wiec dalej okreslenia IaaS.

 

 

@TheOne, przyjmujesz w swoim wywodzie dotyczacym chmury dwa zalozenia, ktore moim zdaniem nie zawsze sa prawdziwe.

Mianowicie:

 

- zalozenie 2-3 krotnie wyzszej ceny serwera w rozwiazaniu IaaS z zarzadzana wirtualizacja vs serwer dedykowany, mysle, ze obecnie jesli spojrzy sie na polskie oferty serwerow dedykowanych mozemy mowic o roznicy dwukrotnie mniejszej 1.5 - 1.8 razy

- zalozenie wspolnego storage dla klientow rozwiazania IaaS, nie wszyscy dostarczyciele infrastruktury podchodza do tematu w ten sposob, my dla przykladu uwazamy, ze istotniejsze jest zmniejszenie ryzyka zwiazanego z padem macierzy niz agregowanie zasobow dyskowych, dlatego do naszych serwerow dajemy direct attached storage

 

Jesli chodzi o potrzebne zaufanie to:

- odnosnie udostepnionych zasobow, tak, potrzeba zaufania, natomiast w rozwiazaniach IaaS, ktore bardziej eksponuja sprzet i daja direct attached storage, tego zaufania potrzeba 'mniej'

- owszem, zaufac nalezy, ze zabezpieczenia dostarczyciela uslugi nie pozwola atakujacemu dostac sie na serwery fizyczne

- odpieranie atakow - to jak rozumiem ten sam argument co punkt wyzej?

 

Jesli zalozymy, ze dostawca IaaS nie prowadzi polityki wspoldzielenia storage oraz klient ma wykupiona instancje wypelniajaca maszyne fizyczna, 'awaria chmury' musi nastapic gdzies w warstwie sieciowej, co implikuje podobny wplyw na usluge serwerow dedykowanych oraz usluge IaaS z instancjami zwirtualizowanymi.

 

Odnosnie stageowania/testowania - oczywiscie, testuje sie w odrebnym srodowisku, w ogromnych instalacjach mamy jednak czesto do czynienia ze stageowaniem, czyli powolnym rolloutem nowych wersji przetestowanego oprogramowania na poszczegolne czesci systemu, co zmniejsza ryzyko wystapienia niewykrytego bledu. Tak czy inaczej tutaj obaj zgadzamy sie, ze IaaS jest lepszy niz dedyki, bo bardziej elastyczny.

 

Owszem, dzielenie serwisu na front i back ma rowniez swoj bardzo istotny aspekt bezpieczenstwa, zgadzam sie. Wydajnosc jest rowniez wieksza, gdyz baza danych lepiej sobie moze radzic z cachowaniem danych, gdy nie musi walczyc o pamiec z pozostalymi serwisami.

 

Kwestie dwoch DC pozostawiam na inne rozwazania, to samo mozna robic w IaaS na dedykach itd, zawsze wiele DC jest rozwiazaniem lepszym niz jedno (chyba, ze ktos nie ma zamiaru duplikowac kosztow serwerow, swoja droga w IaaS, taki backup mozna odpalic on-demand ). Nie dyskutujmy tutaj o tym, to zbyt szeroki temat.

 

Argument odnoszacy sie do zaniku zasilania podpiera sie blednym zalozeniem , ze wszystkie 'chmury' wspoldziela storage. Przy takim zalozeniu, oczywiscie mozesz miec racje i mielismy juz takie przypadki.

 

Bardzo dziekuje za Twoj punkt widzenia, pozwoli nam lepiej zrozumiec sposob myslenia niektorych klientow. Moze bedziemy mogli dodac do naszej oferty rowniez rozwiazania dla nich/dla Ciebie.

 

Stad ponizsze pytania:

 

- czy twoim zdaniem oferta serwerow dedykowanych z cenami podobnymi do OVH/Hetzner ale zlokalizowana w Polsce spotkala by sie z Twoim i innych zainteresowaniem?

 

- byc moze rozwiazanie hybrydowe, gdzie klienci mieliby dostep zarowno do dedykow oraz opcji IaaS na maszynach zwirtualizowanych, jest tym, co pozwoliloby klientom wykorzystac zalety obu rozwiazan u jednego dostawcy?

 

dzieki jeszcze raz za zabranie glosu i prosze o opinie,

 

pozdrawiam,

 

Daniel z Tiktalik Team

 

 

 

 

 

 

 

[theONE 526]

- jezeli jest osobny storage/osobne maszyny dla usera to jest coraz bardziej prywatna chmura a IaaS jesty tylko w odniesieniu do modelu rozliczeń, tak btw jestem całym sercem za prywatna chmurą dla firmy, ale im bardziej skomplikowany produkt tym gorzej

 

- Ceny:

E24Cloude: 12 Core, 24 GB RAM (mało...), 3 TB miejsca (sata 7200 bo nie napisano inaczej) = 477 zł / tydzień = 2146,5 zł miesiąc, brak twardej (wiążącej) informacji co do wydajności dysków więc może być ciężko

 

 

Octawave (trudno dopasować konfiguracje mają kosmiczne ceny ale za to wydajnych dysków SATA) - 16 Core, 32 GB RAM, 4x 300 GB HDD (1x T2 3xT1 na 1 M IOPS co jest śmieszną wartością) = 9000 zł (3000 USD)

 

Ogólnie w polskiej chmurze dużej ilości RAM nie dostaniesz automatycznie...

 

IBM - Za storage 1 TB LOW + 256 GB HI 500 zł, za wypchnięcie 2 TB/500GB ruchu w miesiącu 1150zł , nie byłem w stanie wybrać taniej liczacego środowiska niż 8000 zł i nie da się tego przejść bez pomocy kogoś z IBM żeby być świadomym co do tego co się bierze

 

Serwer 2x 2620 + 24 GB RAM + 2x SSD 240 +2x SATA 2 TB z ATM kosztuje 990 zł za miesiąc

 

- Ataki, chodzi także o głupie ilościowki i ataki na infrastrukturę sieciową, przy dużych wspólnych projektach łatwiej oberwać rykoszetami

 

 

Odpowiediz na pytania:

- czy twoim zdaniem oferta serwerow dedykowanych z cenami podobnymi do OVH/Hetzner ale zlokalizowana w Polsce spotkala by sie z Twoim i innych zainteresowaniem?

 

Są takie oferty i spotykają się, jeżeli ktoś jedzie na cenach jak z OVH/Hetzner w Polsce to przy skali jaką może mieć zwykle oszczędza bardzo i prędzej czy później zaboli to jego klientów, ogólnie nie trzymał bym poważnego biznesu przynoszącego sporo pieniędzy na masowej usłudze, wyjątkiem jest treść która można łatwo trzymać w wielu miejscach i prostym mechanizmem przenosić na inne środowiska

 

- byc moze rozwiazanie hybrydowe, gdzie klienci mieliby dostep zarowno do dedykow oraz opcji IaaS na maszynach zwirtualizowanych, jest tym, co pozwoliloby klientom wykorzystac zalety obu rozwiazan u jednego dostawcy?

 

A prawom murphiego wykorzystać wady obu rozwiązań. Jakbym już robił taki krok to bym zrobił BARDZO DUŻY krok czyli całość przeniósł na współdzielone albo całość zostawił na swojej infrastrukturze. Widziałem już kilka rozwiązań kiedy takie współdzielenie kończyło się pingpongiem odpowiedzialności za wydajność całości. Jedna administracja = jedna odpowiedzialność, dwie administracje = problem

 

 

[Tiktalik.com 18]

My nie wspoldzielimy zasobow dyskowych pomiedzy serwerami, jesli wezmiesz instancje zajmujaca caly serwer fizyczny, jestes sam i masz dla siebie 70 000 IOPS.

 

Rozumiem wiec, ze jako klient, nie wspominajac o cenie:

a) zauwazasz problem z serwerami o duzej ilosci ram w chmurze - trudno dostepne oferty

b) wybierasz dla swoich biznesow dedyki o 'sredniej' cenie, bo nie wierzysz, ze 'tanio' mozna zrobic cos dobrze

 

Dzieki, notujemy punkt widzenia.

 

My mamy zamiar wkrotce odpalic serie 'Eco' w naszym IaaS, czyli serie tanich serwerow i3/i5 8/16/32GB RAM w formie zwirtualizowanej, bez dzielenia zasobow dyskowych (kupujacy instancje o rozmiarach calego serwera ma go dla siebie). Moim zdaniem to bedzie polaczenie dobrej ceny dedyka + latwosc obslugi i elastycznosc.

 

Oczywiscie pozostana kwestie 'zaufania', ktore poruszales.

 

dzieki za wymiane zdan,

 

Daniel