Hosting w Chmurze

[p 3]

Czy w ramach cloud hostingu moge sobie wrzucic na serwer (poprzez jedno konto ftp, znajac takze dane do logowania sie do jednej mojej bazy mysql) kod phpbb by przemo i moge zapomniec o problemach z wydajnoscia a tylko bede dostawal coraz to wieksze FV? Czy tez jednak kod php musze przystosowac do danego cloud hostingu?

W przypadku Cloud Sites dokładnie tak. Chociaż zarówno Cloud Sites jak i Heroku korzystają z MySQL'a i PostreSQL'a (czyli to nie 100% "cloud hosting"), co ogranicza możliwości pojedynczej bazy danych do możliwości pojedynczej maszyny.

W przypadku GAE nie ma takiego ograniczenie ale musiałbyś dostosować kod do GQL'a (albo skorzystać z jakiejś warstwy abstrakcji, tłumaczącej w locie proste zapytania SQL<>GQL).

[ertcap 0]

W przypadku Cloud Sites dokładnie tak. Chociaż zarówno Cloud Sites jak i Heroku korzystają z MySQL'a i PostreSQL'a (czyli to nie 100% "cloud hosting"), co ogranicza możliwości pojedynczej bazy danych do możliwości pojedynczej maszyny.

W przypadku GAE nie ma takiego ograniczenie ale musiałbyś dostosować kod do GQL'a (albo skorzystać z jakiejś warstwy abstrakcji, tłumaczącej w locie proste zapytania SQL<>GQL).

Ok, dzieki anielskiej cierpliwosci jednoliterowca wznosze sie na wyzyny swojego umyslu i staram sie spojrzec na problem z innej strony (a nie tylko na strone wyciagania pieniedzy od klientow).

 

Dazylem do tego, zeby nie wpasc w pulapke zaleznosci do jakiejs jednej komercyjnej platformy - gdzie pozniej ceny za hosting moga ciagle rosnac a czlowiek, poprzez wdrozenie systemu dostosowanego do danej platformy ma problem (i liczy co taniej - czy przerabiac pod inna platforme czy jednak ciagle taniej bedzie to hostowac na obecnej).

 

Pewnie koszt zmiany sposobu laczenia sie z jakas baza danych dostarczana w ramach cloud hostingu moze byc tanszy niz projektowanie od zera softu zdolnego pracowac na wielu maszynach, bez koniecznosci opierania sie na zewn. rozwiazaniach cloud hostingu. Jednak z drugiej strony, majac soft nie wymagajacy instalacji na zewn. platformie cloud hostingu jestesmy bardziej niezalezni (jak nam sie rynek zmonopilzuje i bedziemy mieli np. tylko trzech dostawcow cloud hostingu to ceny hostingu moga przestac odpowiadac faktycznym kosztom).

 

Popraw mnie jesli sie myle - projektujac caly soft wraz z rozlozeniem tego na poszczegolne maszyny (load balancing , przechowywanie danych, trzymanie sesji) de facto tworzymy sobie mala wlasna platforme cloud hostingu?

 

Osobiscie sklaniam sie za projektowaniem wszystkiego od zera ale moze to dlatego, ze lubie wyzwania

[p 3]

Dazylem do tego, zeby nie wpasc w pulapke zaleznosci do jakiejs jednej komercyjnej platformy - gdzie pozniej ceny za hosting moga ciagle rosnac a czlowiek, poprzez wdrozenie systemu dostosowanego do danej platformy ma problem (i liczy co taniej - czy przerabiac pod inna platforme czy jednak ciagle taniej bedzie to hostowac na obecnej).

Trochę zamieszałeś i się pogubiłem. Masz na myśli platformę wirtualizacyjną (VMWare, etc) czy platformę hostingową (GAE, etc)?

 

Popraw mnie jesli sie myle - projektujac caly soft wraz z rozlozeniem tego na poszczegolne maszyny (load balancing , przechowywanie danych, trzymanie sesji) de facto tworzymy sobie mala wlasna platforme cloud hostingu?

Nie myslisz się, więc nie poprawiam

 

Osobiscie sklaniam sie za projektowaniem wszystkiego od zera ale moze to dlatego, ze lubie wyzwania

Ja też, ale chyba nie oczekujesz, że BOSS będzie pod jeden projekt tworzył własną chmurkę?

[ertcap 0]

Trochę zamieszałeś i się pogubiłem. Masz na myśli platformę wirtualizacyjną (VMWare, etc) czy platformę hostingową (GAE, etc)?

W tym przypadku platforme hostingowa.

Ale uprzedzajac Twoja wypowiedz - widze problem z moca bazy danych (jakims MySQLu) gdy przekroczymy wydajnosc jednego fizycznego serwera.

Wydawalo mi sie, ze cloud hostingi oprocz bazy danych wymagaja jeszcze jakis zmian w ramach kodu softu www (w naszym przypadku phpbb by przemo;)) - ale skoro problem bedzie wystepowal tylko przy mocy serwera bazodanowego to faktycznie nic nie zmieni miejsce zastosowania chmury (a dokladniej czy skorzystamy z cloud infrastructure czy tez z cloud hosting). Cloud hosting nawet zachowa sie lepiej przy sofcie gdzie wiekszosc obciazenia bedzie generowalo obsluzenie statycznych danych (w stosunku do jednego mocnego LAMPa w ramach cloud infrastructure).

Z drugiej strony utwierdziles mnie w przekonaniu (za co serdecznie dziekuje ), ze narazie te chmury to nie jest idealne rozwiazanie i nadal najlepiej samemu sobie projektowac skalowalnosc aplikacji

Ja też, ale chyba nie oczekujesz, że BOSS będzie pod jeden projekt tworzył własną chmurkę?

Skoro nie lubi wyzwan...

[p 3]

Ale uprzedzajac Twoja wypowiedz - widze problem z moca bazy danych (jakims MySQLu) gdy przekroczymy wydajnosc jednego fizycznego serwera.

Tylko w przypadku Cloud Sites / Heroku... Z GAE nie ma takiego problemu

 

Chociaż powiedzmy sobie szczerze, jak fatalnie musiałby być napisany kod lub jak duża musiałaby być baza danych, żeby sama przerosła możliwości pojedynczego fizycznego serwera w sensownej konfiguracji sprzętowej? W obecnych czasach, w aplikacjach webowych z cache'owaniem na każdym możliwym poziomie, jest to praktycznie niemożliwe do osiągnięcia

 

Z drugiej strony utwierdziles mnie w przekonaniu (za co serdecznie dziekuje ), ze narazie te chmury to nie jest idealne rozwiazanie i nadal najlepiej samemu sobie projektowac skalowalnosc aplikacji

Niestety tak pozostanie jeszcze przez jakiś czas. Całość rozbija się o rozproszone bazy dane, a raczej ich brak. W chwili obecnej Google jest w posiadaniu jedynej implementacji, która jest używana w środowisku produkcyjnym od lat... Pozostałe, mimo iż bardzo obiecujące, są póki co po prostu za młode aby móc o nie opierać całe platformy hostingowe, dlatego obecnie powstają takie przejściowe "cloud hostingi" z SQL'em

[Wojciech Małota 0]

Dla mnie jedynym sensownym rozwiązaniem chmurkowym jest coś takiego:

- dostaję VPSa z określoną mocą obliczeniową, przestrzenią dyskową etc.

- instaluję na nim co chcę - MySQLe, serwery WWW i co mi się jeszcze podoba

- system VPS pracuje ponad chmurą

- przestrzeń dyskowa VPSa jest rozproszona, pamięć operacyjna jest rozproszona, moc obliczeniowa jest rozproszona i administratora VPSa nie obchodzi na których nodach coś się liczy i gdzie są trzymane jego dane.

 

Póki nie będzie w linuksie takiej platformy wirtualizacyjnej puty wszelkie chmurki będą bez sensu.

Mówienie userom "mamy fajną chmurkę ale zamiast MySQLa musisz użyć GSQLa, a zamiast czegoś tam coś nnego" śmierdzi prowizorką.

 

A może są takie rozwiązania, o których mówię? Może nawet jest jakiś opensource a'la Xen?

[Tomasz Kozlowski 0]

Z góry Was przepraszam za długość tego posta

 

Poczytałem trochę Waszą stronę i jeśli opracujecie to na tej zasadzie:

1. Klient płaci za wykorzystanie zasobów, które w podstawowym pierwszym pakiecie odpowiadają dajmy na to lepszym, topowym pakietom shared.

2. W dowolnej chwili może dokupić zasobów co odpowiadałoby za vps czy też w dedykowi.

 

Takie rozwiązanie w chmurze to co czego mój klient szuka. Po prostu kupuje hosting i wraz z rozwojem, wzrostem ruchu odpowiednio dopasowuje parametry hostingu.

 

ad 1 - na chwilę obecną przyjęliśmy 2GB RAM / 80GB Storage jako parametry wejściowe czyli jednak znacznie więcej niż w jakimkolwiek shared hostingu.. Ale osobiście mocno się zastanawiam nad kontem 1GB / 40GB.

 

ad 2 - dokładnie tak to wygląda. Plus opcja, że można wrócić do mniejszego planu w dowolnej chwili jak zapotrzebowanie spadnie, żadnych kontraktów, można przerwać umowę w dowolnej chwili, itp.

 

A do czego Ci opcja reseller? Chodzi o to, żebyś mógł to samo oferować innym swoim klientom?

 

*ertcap* No ale czy do tego nie powinnismy dazyc?

*p* Absolutnie nie.

 

*ertcap* Dla mnie "hosting w chmurze" (tytul tematu) wlasnie tak mozna zdefiniowac. Uzyszkodnik ma zwykly hosting a z racji zastosowania chmury jako infrastruktury serwerowej ma zapewniona duzo wyzsza skalowalnosc.

*p* Niby w jaki sposób oferuje to skalowalność wychodzącą poza możliwości pojedynczego serwera?

 

IMHO to jest słuszna droga rozwoju

 

A jesli chodzi o skalowalnosc, to prosze Cie.. Roznica jest tak olbrzymia, ze albo sie nie zrozumielismy albo nie wiem co.. Chcesz powiedziec ze nie widzisz roznicy w skalowalnosci pojedynczego serwera a serwera opartego o Cloud'a?

 

1 - Dołożenie RAM'u w zwyklym serwerze to kwestia wyciagania serwera z szafy, rozkrecania, wkladania RAMu i z powrotem do szafy. Downtime jest nieunikniony. Calosc moze trwac od paru godzin do paru dni nawet jak uwzglednimy negocjacje z dzialem handlowym, itp itd.

 

Przy Cloudzie to kwestia minut, jesli nie sekund. Jesli jeszcze do tego jest jakis zgrabny panel to mozesz sobie sam dolozyc ten RAM, bez kontaktu z dzialem obslugi klienta.

 

2 - Jak bedziesz mial kaprys to mozesz sobie dolozyc dodatkowy Cloud'owy serwer kiedy chcesz. Dostaniesz go od reki a za pare godzin mozesz go wylaczyc. Zwyklego serwera nikt Ci nie da od reki, na pare godzin.

 

3 - Tak samo ze Storage'm.. Przy zwyklym serwerze z lokalnym storagem, nawet jak masz dyski hot-swap to poszerzenie przestrzeni dyskowej z 500GB do 5TB to nie taka prosta sprawa.. Cloud pracuje najczesciej na zewnetrznej macierzy i w dowolnym momencie do dowolnego serwera dokladasz dysk o dowolnym rozmiarze.

 

Proszę Was, nie polecajcie BOSS'owi takich rozwiązań. Przecież to tak samo jak byście polecali VPS'a / serwer dedykowany osobie szukającej hostingu współdzielonego, a to jest po prostu złe.

 

Na codzień wyznaje ta sama polityke, ale BOSS (a konkretniej jego klient) ma ewidentnie ambicje na to, zeby z shared hostingu wyrosnac niebawem. Zgadzam sie ze polecanie osobie szukajacej hostingu, serwera z ktorym jedyny kontakt jest przez konsole - to kiepski pomysl.. Ale jesli ten ktos ma miec za chwile spory traffic i ma sie nie zmiescic w shared hostingu to co on ma zrobic? Jedyna opcja to vps / dedyk w wersji managed, zeby sie taki delikwent nie musial przeprawiac przez konsole, itp. Podstawowe pytanie - czy klient woli zainwestowac teraz troche wiecej w skalowalna infrastrukture, czy woli zaczac na shared hostingu a potem ewentualnie sie przeniesc. Jak wiadomo takie przeprowadzki to nigdy nie jest prosty i wygodny proces wiec kwestie finansowe nie zawsze sa najwazniejsze w takich sytuacjach.

 

Ale tu nie chodzi o czepianie się słówek. Tak, postawienie LAMP'a w chmurze można nazwać "hostingiem w chmurze", bo tym dokładnie jest, natomiast nie ma to kompletnie nic wspólnego z "cloud hostingiem" (GAE, Heroku czy Cloud Sites). Z technologicznego punktu widzenia są to tak różne bestie, że nawet nie ma sensu tego prównywać.

 

To są różne bestie, ale nie do końca. Heroku na przykład stoi na Amazonie Zatem warstwa sprzętowa to podręcznikowy Cloud Infrastructure. Skalowalność na tym poziomie jest niezbędna, żeby stworzyć skalowalność na kolejnych warstwach.

 

*p* Czy w ramach cloud hostingu moge sobie wrzucic na serwer (poprzez jedno konto ftp, znajac takze dane do logowania sie do jednej mojej bazy mysql) kod phpbb by przemo i moge zapomniec o problemach z wydajnoscia a tylko bede dostawal coraz to wieksze FV? Czy tez jednak kod php musze przystosowac do danego cloud hostingu?

 

*ertcap* W przypadku Cloud Sites dokładnie tak. Chociaż zarówno Cloud Sites jak i Heroku korzystają z MySQL'a i PostreSQL'a (czyli to nie 100% "cloud hosting"), co ogranicza możliwości pojedynczej bazy danych do możliwości pojedynczej maszyny.

W przypadku GAE nie ma takiego ograniczenie ale musiałbyś dostosować kod do GQL'a (albo skorzystać z jakiejś warstwy abstrakcji, tłumaczącej w locie proste zapytania SQL<>GQL).

 

Przy czym te "mozliwosci pojedynczej maszyny" mozna tez tak naprawde skalowac w nieskonczonosc wiec nie ma limitu.. IBM wypuścił ostatnio ciekawą linię serwerów pod wirtualizację. Pojedynczy taki serwer przyjmuje do 256GB RAM. Cztery takie serwery można spiąć razem, tak że zachowują się jak jedna maszyna (jeden login, itp). Mamy więc już serwer z 1 TB RAM. Twoje phpbb by przemo ma taki ruch zeby sie serwer przytkal? To nie koniec, bo dalej 4 takie serwery można znów spiąć w jeden, itp itd.

 

@ertcap - Nie musisz pisac specjalnego kodu, zeby skalowanie dzialalo z konkretna platforma. Nie jestes w zaden sposob "uwiazany" do konkretnego dostawcy. Ba - bariera wyjscia tak na prawde moze byc znacznie nizsza niz w przypadku klasycznych rozwiazan. Niektorzy dostawcy Cloud'owi oferuja (za symboliczna oplata) eksport obrazu Twojego serwera. Z takim obrazem mozesz isc do dowolnego innego dostawcy i umiescic ten obraz na innej (tanszej / lepszej / whatever) infrastrukturze. Odpada Ci przy tym cala masa roboty zwiazanej z przenoszeniem danych, konfiguracja serwera, itp itd.

 

Poza tym skad pomysl, ze Cloud to pomysl na wyciaganie pieniedzy od klientow? Jest przeciez dokladnie odwrotnie

 

*ertcap* Popraw mnie jesli sie myle - projektujac caly soft wraz z rozlozeniem tego na poszczegolne maszyny (load balancing , przechowywanie danych, trzymanie sesji) de facto tworzymy sobie mala wlasna platforme cloud hostingu?

 

*p* Nie myslisz się, więc nie poprawiam

 

Obawiam się, że nie mogę się zgodzić. Mylisz skalowalnosc aplikacji i skalowalnosc infrastruktury. Rozproszenie aplikacji to generalnie bardzo dobry pomysł, ale to NIE zastępuje Cloud'a.. Załóżmy, że masz forum o piłce nożnej. Na czas ligi mistrzów czy euro 2012 masz pewnie 10 razy wiekszy ruch. Potrzebujesz wiec rozbudowac infrastrukture. Kupujesz wiec 2 nowe serwery do klastra i po kłopocie, tak? Albo jeśli je dzierżawisz to poprostu dzierżawisz dwa nowe tak? Pamietaj, ze poodpisujesz przy tym cyrograf pewnie na 3 lata. Dolozenie tych serwerow zajmuje w zaleznosci od formy (dzierzawa, kupno, leasing, itp) od paru dni do pewnie nawet miesiaca albo i lepiej. A po lidze mistrzów ruch na forum wraca do pierwotnego i co robisz z tymi dodatkowymi serwerami? Placisz za nie caly czas choc nie potrzebujesz, a oddac nie mozesz..

 

W przypadku Infrastruktury Cloud'owej jak potrzebujesz nowy serwer to dostajesz go w ciagu PARU MINUT od zlozenia zamowienia. A dodatkowo jak tylko przestaniesz go potrzebowac to przestajesz placic i odlaczasz maszyne. Calosc kosztuje Cie o WIELE mniej.

 

A jesli zabraknie Ci miejsca na dysku to co zrobisz? Bedziesz wymienial dyski i przenosil dane ze starych na nowe? Przy Cloudzie w dowolnej chwili mozesz sobie przydzielic kolejne zasoby dyskowe i w dowolnej chwili mozesz z nich zrezygnowac.

 

Pomijam juz to, ze jak madrze podzielisz infrastrukture na rozproszone maszyny to na poziomie skalowania maszyn samych w sobie (dokladanie storage'u, RAM'u, itp) jestes w stanie osiagnac BARDZO duza elastycznosc. A jednak znacznie latwiej jest zarzadzac infrastruktura ktora ma kilka mocny serwerow niz kilkanascie slabszych.

 

Wreszcie najwazniejsze - jak robisz to sam, na zwyklych serwerach tyle ze w strukturze rozproszonej - to wciaz musisz sie martwic o hardware.. awarie dyskow, przepalony RAM, itp itd. Cloud sam sie leczy i jak dane zasób ulegnie uszkodzeniu - przydziela nowy. Całość transparentna dla klienta.

 

Podstawowe pytanie które należy sobie zadać to "na czym zarabiam?" Na tym że rozwijam forum, zdobywam userów, itp. Czy na tym, że buduję sobie własną "chmurke" i tracę czas na wymyślanie koła na nowo? Rozumiałbym, gdyby to jeszcze miało zaoszczędzić Ci jakiekolwiek pieniądze, ale tak nie jest.. Bo robiąc to "na własną rękę" zapłacisz O WIELE więcej niż korzystając z gotowej chmurki.

 

Jeśli miałbym znaleźć jakieś proste porównanie klasyczny serwer vs cloud to powiedziałbym, że klasyczny serwer dedykowany to tak jak własna dedykowana studnia, a Cloud to jak nielimitowany dostęp do sieci wodociągów.. Jak potrzebujesz wodę to odkręcasz kurek, jak potrzebujesz więcej to odkręcasz mocniej. Płacisz defacto za to co zużyjesz.

 

Dla mnie jedynym sensownym rozwiązaniem chmurkowym jest coś takiego:

- dostaję VPSa z określoną mocą obliczeniową, przestrzenią dyskową etc.

- instaluję na nim co chcę - MySQLe, serwery WWW i co mi się jeszcze podoba

- system VPS pracuje ponad chmurą

- przestrzeń dyskowa VPSa jest rozproszona, pamięć operacyjna jest rozproszona, moc obliczeniowa jest rozproszona i administratora VPSa nie obchodzi na których nodach coś się liczy i gdzie są trzymane jego dane.

 

Póki nie będzie w linuksie takiej platformy wirtualizacyjnej puty wszelkie chmurki będą bez sensu.

Mówienie userom "mamy fajną chmurkę ale zamiast MySQLa musisz użyć GSQLa, a zamiast czegoś tam coś nnego" śmierdzi prowizorką.

 

A może są takie rozwiązania, o których mówię? Może nawet jest jakiś opensource a'la Xen?

 

Błagam nie nazywajmy tego VPS'em bo technologia która stoi za Cloudem i VPSem jednak mocno się różni

 

Mniej więcej tak działa ServeCloud (jeśli dobrze Cię zrozumiałem).

 

Rozwiązania opensource tego typu chyba nie ma póki co...

[Tomasz Fiedoruk 98]

ad 1 - na chwilę obecną przyjęliśmy 2GB RAM / 80GB Storage jako parametry wejściowe czyli jednak znacznie więcej niż w jakimkolwiek shared hostingu.. Ale osobiście mocno się zastanawiam nad kontem 1GB / 40GB.

Hmm nie wiem na jakiej zasadzie jest wyliczane bazowe obciążenie przez środowisko i panel per klient ale myślę że na start to i 512MB/10GB byłoby wskazane (no chyba że ten 1GB/40GB będzie tani to wtedy nie trzeba ).

 

A do czego Ci opcja reseller? Chodzi o to, żebyś mógł to samo oferować innym swoim klientom?

Ogólnie zastosowania panelu reseller można podzielić na dwa przypadki;

1. Gdy webdeveloper chce utrzymywać swoich klientów i potrzebuje rozdzielenia praw dostępu.

2. Gdy webdeveloper trzyma każdy projekt czy każdą domenę na innym subkoncie dla zachowania przejrzystości i wygody pracy.

[Tomasz Kozlowski 0]

Hmm nie wiem na jakiej zasadzie jest wyliczane bazowe obciążenie przez środowisko i panel per klient ale myślę że na start to i 512MB/10GB byłoby wskazane (no chyba że ten 1GB/40GB będzie tani to wtedy nie trzeba ).

 

Wiesz, mozna zaczac tez od 128MB ram.. tylko ServeCloud nie do konca celuje w ta grupe klientow.. Choc nie wykluczam wypuszczenia w przyszlosci serii serwerow ServeCloudMini z wlasnie takimi parametrami.. Ale na chwile obecna nie ma tego nawet w planach..

 

Zdefniuj "tani" Jaka Twoim zdaniem kwota bylaby fair za skalowalny cloud server o parametrach 1gb / 40gb, postawiony w Polskim DC?

 

Ogólnie zastosowania panelu reseller można podzielić na dwa przypadki;

1. Gdy webdeveloper chce utrzymywać swoich klientów i potrzebuje rozdzielenia praw dostępu.

2. Gdy webdeveloper trzyma każdy projekt czy każdą domenę na innym subkoncie dla zachowania przejrzystości i wygody pracy.

 

Platforma do resellingu wirtualnych maszyn jest w planie, ale to znów raczej przyszłość.. Póki co na Twoje potrzeby mam dwie propozycje:

 

1 - Osobne maszyny dla poszczegolnych klientow z jakims preferencyjnym cennikiem dla Ciebie, jako stałego klienta. W Twoim panelu bedziesz mial oczywiscie podglad wszystkich maszyn, obciazenie, stan faktur, itp. Ale to nie bedzie taki panel o jakim myslisz.. tzn z poziomu tego panelu nie utworzysz nowego konta pocztowego dla Klienta X.

 

2 - Jedna maszyna, na której stawiasz swoja własną platformę shared hostingowa. Tworzysz tam konta dla klientow, kazdemu wedlug potrzeb, kazdy klient moze sie zalogowac do swojego panelu, itp itd. Jak przybywa Klientów to rozbudowujesz maszyne o kolejny storage i kolejne GB ramu.

 

To czy wybierzesz opcje 1 czy 2 zalezy przede wszystkim od tego jakiej skali to sa klienci i co konkretnie ma robic aplikacja danego klienta. Oczywiscie w gre wchodzi rowniez hybrydowe rozwiazanie.

[Wojciech Małota 0]

Błagam nie nazywajmy tego VPS'em bo technologia która stoi za Cloudem i VPSem jednak mocno się różni

 

A dlaczego mam nie nazywać tego VPSem?

VPS = Virtual Private Server

 

Virtual - nie mam fizycznej maszyny tylko wirtualny system

Private - tylko ja mam do niego dostęp oraz mam zagwarantowane zasoby sprzętowe

Server - mogę na nim postawić aplikację jaka mi się podoba

 

czy VPS pracujący w cloudzie nie spełnia, którejś z tych cech?

 

A teraz pytanie laika. Jest jakiś soft do stawiania takich cloudowych vpsów? Komercyjny, opensourcowy? Czy też trzeba sobie samemu napisać?

[Tomasz Kozlowski 0]

A dlaczego mam nie nazywać tego VPSem?

VPS = Virtual Private Server

 

Virtual - nie mam fizycznej maszyny tylko wirtualny system

Private - tylko ja mam do niego dostęp oraz mam zagwarantowane zasoby sprzętowe

Server - mogę na nim postawić aplikację jaka mi się podoba

 

czy VPS pracujący w cloudzie nie spełnia, którejś z tych cech?

 

Masz oczywiście rację z definicją VPS'a. Chodzi mi o to, że do postawienia "zwykłego" VPS'a wystarczy tak na prawdę stary serwer czy nawet PeCet podpięty do sieci. A zbudowanie VPS'a opartego o Cloud'ową Infrastrukturę wymaga znacznie większej inwestycji. Myślę, że nie przesadzę, jak powiem, że ponad 100-krotnie większej inwestycji

 

Z mojego punktu widzenia nazywanie Cloud'owego serwera VPS'em jest krzywdzące i może wprowadzić w błąd, bo pod spodem leży zupełnie inna technologia, która oferuje zupełnie inne możliwości.

 

Z drugiej strony maluch to samochód i Aston Martin to też samochód. Ma 4 koła, kierownicę i silnik. Niczym się nie różnią

 

A teraz pytanie laika. Jest jakiś soft do stawiania takich cloudowych vpsów? Komercyjny, opensourcowy? Czy też trzeba sobie samemu napisać?

 

Co masz na myśli konkretnie? Żeby postawić cloud'owego VPSa trzeba mieć najpierw Cloud'a, w sensie platforme Jeśli masz to w planie to jest kilka softów tego typu (głównie komercyjne), ale mnie osobiscie zaden w 100% nie przypadl do gustu.. Choc duzo zalezy od tego na jaki system wirtualizacji sie zdecydujesz. Jest sporo ograniczen, ale oczywiscie wszystko zalezy od tego co konkretnie chcesz osiagnac.

 

Generalnie wciaz jest imho nisza na zbudowanie DOBREJ aplikacji do stawiania i zarzadzania maszynami opartymi o platforme cloud'owa.

[Tomasz Fiedoruk 98]

Wiesz, mozna zaczac tez od 128MB ram.. tylko ServeCloud nie do konca celuje w ta grupe klientow.. :

Hmm to zależy, bo widzę że Ty idziesz w kierunku całkowicie wydzielonych środowisk vps w chmurze więc i ram by się musiał zaczynać od 256-512, ja myślałem o mniej wydzielonych środowiskach gdzie RAM byłby całkowicie przeznaczony na strony klienta a nie utrzymanie jeszcze środowiska.

 

Platforma do resellingu wirtualnych maszyn jest w planie, ale to znów raczej przyszłość.. Póki co na Twoje potrzeby mam dwie propozycje:

Nie nie Nie reselling wirtualnych maszyn tylko subkont zarządzania www/mysql/mail/ftp.

[Gość Bartosz Gadzimski]

Dla dobra wszystkich uważam, że od "teraz" należy terminu VPS używać w kontekście "starych" vps'ów wydzielonych na jednej fizycznie maszynie.

[Tomasz Kozlowski 0]

Dla dobra wszystkich uważam, że od "teraz" należy terminu VPS używać w kontekście "starych" vps'ów wydzielonych na jednej fizycznie maszynie.

 

Podpisuje sie jak najbardziej

[Wojciech Małota 0]

Dla dobra wszystkich uważam, że od "teraz" należy terminu VPS używać w kontekście "starych" vps'ów wydzielonych na jednej fizycznie maszynie.

 

Problem w tym, że osoby, nie chcą używać terminu VPS w odniesieniu do wirtualnych systemów uruchamianych w chmurze mylą dziedziny. Termin "VPS" nie definiuje infrastruktury - czyli tego czy VPS jest uruchamiany na starym złomie stojącym pod biurkiem, kolokowanym serwerze czy chmurze. "VPS" oznacza, że klient ma do dyspozycji wirtualny system, z gwarantowanymi zasobami, na który nikt inny mu się nie wchrzani.

Natomiast to na czym VPS jest uruchamiany (na OpenVZ, Xenie, VServerze czy Cloudzie) to już zupełnie inna bajka. Osobiście nie widzę nic zdrożnego w nazywaniu "VPSem" VPSa uruchamianego w chmurze bo tym w istocie jest wirtualny system uruchamiany w chmurze.

[p 3]

- przestrzeń dyskowa VPSa jest rozproszona, pamięć operacyjna jest rozproszona, moc obliczeniowa jest rozproszona i administratora VPSa nie obchodzi na których nodach coś się liczy i gdzie są trzymane jego dane.

Nie spodziewaj się takich cudów w najbliższym czasie

 

Mówienie userom "mamy fajną chmurkę ale zamiast MySQLa musisz użyć GSQLa, a zamiast czegoś tam coś nnego" śmierdzi prowizorką.

Jaką znowu prowizorką? Od kiedy bazy danych inne niż MySQL muszą być zgodne z protokołem jaki on wykorzystuje? MySQL nigdy nie był żadnym standardem, poza tym nic tak nie spowalnia rozwoju / innowacyjności jak próba zachowania "wstecznej" kompatybilności z obecnie istniejącymi rozwiązaniami.

 

Zcentralizowane bazy danych się po prostu do chmurki nie nadają i im wcześniej ludzie to sobie uświadomią tym lepiej.

 

A jesli chodzi o skalowalnosc, to prosze Cie.. Roznica jest tak olbrzymia, ze albo sie nie zrozumielismy albo nie wiem co.. Chcesz powiedziec ze nie widzisz roznicy w skalowalnosci pojedynczego serwera a serwera opartego o Cloud'a?

(...)

Wszystko co napisałeś się zgadza, ale tylko do pewnego momentu.

 

Załóżmy, że Twoje serwery fizyczne to Xeon'y 5570 z 18GB RAM'u. Załóżmy, że wyjściową jednostką będzie u Ciebie "kawałek" o wspomnianym wcześniej rozmiarze 2GB RAM'u. W uproszczeniu daje Ci to 9 "kawałków". Wszystko skaluje się do czasu, kiedy działamy w obrębie jednej fizycznej maszyny. A co się stanie w momencie kiedy Twój klient będzie nagle potrzebować mocy odpowiadającej 3 fizycznym maszynom (27 "kawałków")? Będzie płacz i zgrzytanie zębami Jasne, możesz zaoferować mu 3 "extra duże Premium VPS'y" (), ale żeby miało to dla niego jakiekolwiek zastosowanie, to musi on przerobić swoją aplikację tak, aby działała na kilku maszynach.

 

To jest standardowy problem ze skalowalnością w górę (vertical scalability / "scale up") i dlatego od lat co rozsądniejsi starają się skalować w szerz (horizontal scalability / "scale out").

 

Jedyna opcja to vps / dedyk w wersji managed

...albo wspominany cały czas "cloud hosting"

 

To są różne bestie, ale nie do końca. Heroku na przykład stoi na Amazonie Zatem warstwa sprzętowa to podręcznikowy Cloud Infrastructure. Skalowalność na tym poziomie jest niezbędna, żeby stworzyć skalowalność na kolejnych warstwach.

Natomiast Cloud Sites i GAE już nie

 

Zgadza się, jakaś skalowalność na tym poziomie jest niezbędna, natomiast nie widzę potrzeby tworzenia "cloud hostingu" w oparciu Cloud Infrastructure.

 

Przy czym te "mozliwosci pojedynczej maszyny" mozna tez tak naprawde skalowac w nieskonczonosc wiec nie ma limitu.. IBM wypuścił ostatnio ciekawą linię serwerów pod wirtualizację. Pojedynczy taki serwer przyjmuje do 256GB RAM. Cztery takie serwery można spiąć razem, tak że zachowują się jak jedna maszyna (jeden login, itp). Mamy więc już serwer z 1 TB RAM. Twoje phpbb by przemo ma taki ruch zeby sie serwer przytkal? To nie koniec, bo dalej 4 takie serwery można znów spiąć w jeden, itp itd.

O ile nie stosujesz takich serwerów u siebie (a nie stosujesz, bo byłoby to po prostu finansowo nieopłacalne), to taka informacja jest jedynie ciekawostką.

 

Obawiam się, że nie mogę się zgodzić. Mylisz skalowalnosc aplikacji i skalowalnosc infrastruktury. Rozproszenie aplikacji to generalnie bardzo dobry pomysł, ale to NIE zastępuje Cloud'a..

Nic nie mylę, natomiast Ty niepotrzebnie spłycasz dyskusję z

"zwykły" hosting działający w Cloud Infrastruture vs "cloud hosting"

do

Cloud Infrastructure vs serwery dedykowane.

 

Wreszcie najwazniejsze - jak robisz to sam, na zwyklych serwerach tyle ze w strukturze rozproszonej - to wciaz musisz sie martwic o hardware.. awarie dyskow, przepalony RAM, itp itd. Cloud sam sie leczy i jak dane zasób ulegnie uszkodzeniu - przydziela nowy. Całość transparentna dla klienta.

Tak samo jak "cloud hosting".

 

Błagam nie nazywajmy tego VPS'em bo technologia która stoi za Cloudem i VPSem jednak mocno się różni

Ale od strony funkcjonalnej, dla użytkownika końcowego, to jest tylko VPS z bajerami

 

Mniej więcej tak działa ServeCloud (jeśli dobrze Cię zrozumiałem).

Nie widziałem ServeCloud, ale mam wrażenie, że jednak nie działa do końca tak, jak opisał to Wojtek

 

Hmm to zależy, bo widzę że Ty idziesz w kierunku całkowicie wydzielonych środowisk vps w chmurze więc i ram by się musiał zaczynać od 256-512, ja myślałem o mniej wydzielonych środowiskach gdzie RAM byłby całkowicie przeznaczony na strony klienta a nie utrzymanie jeszcze środowiska.

Bo ServeCloud to Premium VPS'y (Cloud Infrastructure), a nie "cloud hosting" (Cloud Platform).

 

Dla dobra wszystkich uważam, że od "teraz" należy terminu VPS używać w kontekście "starych" vps'ów wydzielonych na jednej fizycznie maszynie.

Daj spokój Jeżeli nie masz żadnych sensownych argumentów, to jednak nadal pozostane przy terminie Premium VPS

[ertcap 0]

Przy czym te "mozliwosci pojedynczej maszyny" mozna tez tak naprawde skalowac w nieskonczonosc wiec nie ma limitu.. IBM wypuścił ostatnio ciekawą linię serwerów pod wirtualizację. Pojedynczy taki serwer przyjmuje do 256GB RAM. Cztery takie serwery można spiąć razem, tak że zachowują się jak jedna maszyna (jeden login, itp). Mamy więc już serwer z 1 TB RAM. Twoje phpbb by przemo ma taki ruch zeby sie serwer przytkal? To nie koniec, bo dalej 4 takie serwery można znów spiąć w jeden, itp itd.

Ok, ale wszystko sie rozbija o koszty. Jezeli roczny koszt Premium VPS (podoba mi sie te okreslenie wiec go bede uzywal), ktory bedzie slabej wydajnosci i raz na jakis czas bedzie mocno zwiekszany bedzie na poziomie ceny kilku serwerow dedykowanych w innej firmie (gdzie mam 24/7/365 dostep do pelnej mocy maszyn) to wybor Premium VPSa nie bedzie juz taki oczywisty. Pamietaj o tym, ze koszt serwera dedykowanego w Polsce (nie mowie tu o jakis pececikach) nie jest juz dosc wysoki (w niektorych firmach) i zbliza sie powoli do kosztow zachodnich.

@ertcap - Nie musisz pisac specjalnego kodu, zeby skalowanie dzialalo z konkretna platforma.

Jw.

Koszt duuuuuuzych serwerow jest wielokrotnie wiekszy niz suma kosztow mniejszych serwerow (np. 2 quady, 24GB ram) przy takiej samej wydajnosci.

Moze sie okazac, ze taniej wyjdzie zaprojektowac skalowalna aplikacje niz kupowac jednego wielkiego Premium VPSa. A dodatkowo jestesmy zupelnie niezalezni pozniej w doborze infrastruktury sprzetowej.

Poza tym skad pomysl, ze Cloud to pomysl na wyciaganie pieniedzy od klientow? Jest przeciez dokladnie odwrotnie

Stad, ze w branzy juz siedze iles lat. Do dzisiaj duma mnie rozpiera (mowie to z przymruzeniem oka oczywiscie), ze trafnie wytypowalem, ktore portale upadna a ktore w .pl zostana (ilu z Was pamieta czasy Areny, Ahoja, Yoyo za czasow ich rozwoju?)

Przezylem czasy wyceniania wartosci firm za pomoca ilosci zaloznych kont pocztowych, czasy "kazdy pisze swojego bloga", chore podniecanie sie blade'ami, przezyje pewnie i podniecanie sie chmurami

Albo jeśli je dzierżawisz to poprostu dzierżawisz dwa nowe tak? Pamietaj, ze poodpisujesz przy tym cyrograf pewnie na 3 lata.

Strasznie demonizujesz. Kto Ci w polsce kaze podpisywac cyrograf na 3 lata?

Dolozenie tych serwerow zajmuje w zaleznosci od formy (dzierzawa, kupno, leasing, itp) od paru dni do pewnie nawet miesiaca albo i lepiej. A po lidze mistrzów ruch na forum wraca do pierwotnego i co robisz z tymi dodatkowymi serwerami? Placisz za nie caly czas choc nie potrzebujesz, a oddac nie mozesz..

Ale tu nie chodzi zeby placic tylko za wykorzystana infrastrukture. Problem polega na tym, zeby placic jak najmniej w skali roku / kilku lat.

Czekam z niecierpliwoscia ile bedzie kosztowal w .pl Premium VPS o parametrach typu 8 quadow, 128GB ramu i wtedy sobie porownam czy taniej wyjdzie kupic takiego Premium czy tez kupic kilka serwerow dedykowanych i samemu sobie stworzyc skalowalnosc na poziomie aplikacji. Nawet przy zalozeniu, ze nie zawsze bede korzystal z tej pelnej mocy i koszt Premium VPSa bedzie nizszy (placac za faktycznie zuzyta moc).

Wreszcie najwazniejsze - jak robisz to sam, na zwyklych serwerach tyle ze w strukturze rozproszonej - to wciaz musisz sie martwic o hardware.. awarie dyskow, przepalony RAM, itp itd.

Wcale nie. Skalowalnosc zapewnia mi redundancje, awariami sprzetowymi zajmuje sie DC w przeciagu paru h od zgloszenia.

Cloud sam sie leczy i jak dane zasób ulegnie uszkodzeniu - przydziela nowy. Całość transparentna dla klienta.

Ja wiem jak dziala cloud, cennik firmy na v mam pratycznie w glowie (przy roznych konfiguracjach dla roznej wielkosci chmury, itd.). Stad tez z niecierpliwoscia czekam na dobra oferte cenowa (bo nie do konca wierze, ze ona bedzie dobra i bedzie mogla skutecznie konkurowac z serwerami dedykowanymi).

Podstawowe pytanie które należy sobie zadać to "na czym zarabiam?" Na tym że rozwijam forum, zdobywam userów, itp. Czy na tym, że buduję sobie własną "chmurke" i tracę czas na wymyślanie koła na nowo?

Moj zarobek to przychod minus koszty. Wazne sa dla mnie koszty. I w sumie dla wszystkich. Takze z niecierpliwoscia czekam na Twoja oferte cenowa, ktora sobie porownam z innymi rozwiazaniami (nie zwiazanymi z chmurami).

[Wojciech Małota 0]

Nie spodziewaj się takich cudów w najbliższym czasie

Wiem, dlatego uważam, że Clud<Cokolwiek> śmierdzi.

 

Jaką znowu prowizorką? Od kiedy bazy danych inne niż MySQL muszą być zgodne z protokołem jaki on wykorzystuje? MySQL nigdy nie był żadnym standardem, poza tym nic tak nie spowalnia rozwoju / innowacyjności jak próba zachowania "wstecznej" kompatybilności z obecnie istniejącymi rozwiązaniami.

 

Źle mnie zrozumiałeś. MySQLa użyłem tylko jako przykład. CloudHosting będzie dopiero wtedy dobrym rozwiązaniem, kiedy użytkownika chmury nie będzie obchodziło to, że jego oprogramowanie pracuje w chmurze. Oznacza to, że chmura musiałaby być tak zaprogramowana aby oprogramowanie w niej pracujące nie wiedziało (i nie musiało wiedzieć!), że pracuje w chmurze. Stąd przykład z MySQLem. Jeżeli użytkownik systemu pracującego w chmurze będzie mógł sobie użyć bazy MySQL (bo akurat taką lubi),a nie będzie musiał się przesiadać na jakieś GSQL (bo to akurat potrafi pracować w chmurze) to wtedy będzie można powiedzieć, że chmury są dobre i nie śmierdzą.

[beliq 442]

Wiem, dlatego uważam, że Clud<Cokolwiek> śmierdzi.

Toż napisałem to już dwie strony temu. Oracla na tym nie postawisz, firmy hostingowej nie otworzysz

i jeszcze taki czy inny jednoliterowiec Ci powie, że Twój soft jest bee i masz użyć innego.

 

Odkąd pamiętam programiści męczyli się, aby soft do prowadzenia rozproszonych obliczeń

mógł także obsługiwać rozproszone przetwarzanie zadań np. serwerów www, bazodanowych.

Nie udało im się to, więc się wycwanili i zaczęli pisać nowy soft narzucając go tym samym ludziom

jako -> jedyny słuszny <-.

 

Założenie jest jakże piękne, ale z wykonaniem gorzej.

Cóż, faszyzm też miał być piękny - podobno...

[p 3]

Źle mnie zrozumiałeś. MySQLa użyłem tylko jako przykład. CloudHosting będzie dopiero wtedy dobrym rozwiązaniem, kiedy użytkownika chmury nie będzie obchodziło to, że jego oprogramowanie pracuje w chmurze. Oznacza to, że chmura musiałaby być tak zaprogramowana aby oprogramowanie w niej pracujące nie wiedziało (i nie musiało wiedzieć!), że pracuje w chmurze.

Nie spodziewaj się takich rozwiązań. Jakakolwiek synchronizacja jest bardzo kosztowna i należy jej unikać, a to o czym piszesz wymagałoby synchronizacji na praktycznie każdym poziomie.

 

firmy hostingowej nie otworzysz

Kłóciłbym się

 

jeszcze taki czy inny jednoliterowiec Ci powie, że Twój soft jest bee i masz użyć innego.

Twój system operacyjny jest bee

[Wojciech Małota 0]

Odkąd pamiętam programiści męczyli się, aby soft do prowadzenia rozproszonych obliczeń

mógł także obsługiwać rozproszone przetwarzanie zadań np. serwerów www, bazodanowych.

Nie udało im się to, więc się wycwanili i zaczęli pisać nowy soft narzucając go tym samym ludziom

jako -> jedyny słuszny <-.

 

Generalnie pójście w takim kierunku aby soft serwerowy obsługiwał rozproszone przetwarzanie żądań jest dobre. Jeżeli obecnego softu nie da się przerobić to trzeba napisać od nowa - nie ma rady. Natomiast migracja będzie baaaardzo powolna bo nowy soft najpierw musi udowodnić swoją stabilność, a potem rzesze programistów będą musiały przerobić swoje oprogramowanie klienckie. Idea hostingu w chmurce mi osobiście się bardzo podoba natomiast jest to pieśń bardzo dalekiej przyszłości. Podejrzewam, że najpierw model von Neumanna zostanie zastąpiony czymś innym.

[beliq 442]

Twój system operacyjny jest bee

Moja wina, że system zalecany przez Ciebie i OpenBGPd mnie ewidentnie -> nie lubią <-, (*)

a na Debianie ten sam efekt udało mi się osiągnąć w 15 minut z zegarkiem w ręku?

Zły dotyk boli, całe życie... chociaż kiedyś jeszcze z pewnością dam OpenBSD drugą szansę,

bo to że się z nim ewidentnie nie umiem dogadać wcale nie oznacza, że mi się on nie podoba.

 

(*) ani mi się waż, nie kombinuj, czytałem manual

[p 3]

(*) ani mi się waż, nie kombinuj, czytałem manual

A FAQ?

[Prohost 345]

Cloudy są zbyt skomplikowane aby je zwykły user używał. Soft popularny to problem na cloudzie. Niestety jeszcze dużo czasu minie zanim popularne i niedrogie serwery będą miały OSa i hardware wspierające łączenie serwerów (głównie chodzi tu o szeroki interfejs do szybkiej wymiany danych między serwerami). W obecnych serwerach można użyć sieci do wymiany danych ale jest to zbyt wolne i wiadomo, że nie jest to na poziomie sprzętu i zasoby się muszą męczyć nad tym.

 

Tanie serwery które można połączyć i os obsługujący to będzie dopiero cloud. W tej chwili wszystko jest takie "emulowane" i nienaturalne, że ciężko coś z tym robić.

 

Według mnie nie będzie prawdziwego clouda bez hardware. Soft to tylko bardzo ograniczona emulacja tego jak to powinno działać.

 

Nie mówię tu o super serwerach bo wiadomo, że kto może sobie na to pozwolić.

[Tomasz Kozlowski 0]

Hmm to zależy, bo widzę że Ty idziesz w kierunku całkowicie wydzielonych środowisk vps w chmurze więc i ram by się musiał zaczynać od 256-512, ja myślałem o mniej wydzielonych środowiskach gdzie RAM byłby całkowicie przeznaczony na strony klienta a nie utrzymanie jeszcze środowiska.

 

Tak, bo idea jest taka, żeby ta maszyna zachowywała się tak jak klasyczny dedykowany serwer (w sensie niezaleznosci).

 

*Wojciech Małota* przestrzeń dyskowa VPSa jest rozproszona, pamięć operacyjna jest rozproszona, moc obliczeniowa jest rozproszona i administratora VPSa nie obchodzi na których nodach coś się liczy i gdzie są trzymane jego dane.

 

*p* Nie spodziewaj się takich cudów w najbliższym czasie

 

Spodziewaj się idea cloud'a jest taka, żeby user nie myślał w ogóle o sprzęcie. Interesuje go moc obliczeniowa na poziomie X, przestrzen dyskowa na poziomie Y i koniec. Skad sie to bierze.. to nie jego problem.

 

poza tym nic tak nie spowalnia rozwoju / innowacyjności jak próba zachowania "wstecznej" kompatybilności z obecnie istniejącymi rozwiązaniami.

 

Zgadzam sie w 100% procentach, ale jak bariera wejscia bedzie zbyt wysoka to innowacyjny produkt (chocby byl 3 razy lepszy) sie poprostu nie przyjmie.

 

Wszystko co napisałeś się zgadza, ale tylko do pewnego momentu.

 

Załóżmy, że Twoje serwery fizyczne to Xeon'y 5570 z 18GB RAM'u. Załóżmy, że wyjściową jednostką będzie u Ciebie "kawałek" o wspomnianym wcześniej rozmiarze 2GB RAM'u. W uproszczeniu daje Ci to 9 "kawałków". Wszystko skaluje się do czasu, kiedy działamy w obrębie jednej fizycznej maszyny. A co się stanie w momencie kiedy Twój klient będzie nagle potrzebować mocy odpowiadającej 3 fizycznym maszynom (27 "kawałków")? Będzie płacz i zgrzytanie zębami Jasne, możesz zaoferować mu 3 "extra duże Premium VPS'y" (), ale żeby miało to dla niego jakiekolwiek zastosowanie, to musi on przerobić swoją aplikację tak, aby działała na kilku maszynach.

 

To jest standardowy problem ze skalowalnością w górę (vertical scalability / "scale up") i dlatego od lat co rozsądniejsi starają się skalować w szerz (horizontal scalability / "scale out").

 

Jak klient będzie potrzebował maszynę odpowiadającą 3 fizycznym maszynom to ją dostanie

 

Zgadzam się, że skalowanie wszerz jest sprytniejsze, aczkolwiek wymaga pewnego nakładu pracy po stronie twórcy aplikacji. Jeśli od początku budujesz aplikację z myślą o tym to OK. Ale w większości przypadków scenariusz wygląda tak, że jest aplikacja, która "nie mieści" się na obecnym serwerze i pojawia się pytanie co dalej. Dołożyć RAM i działać dalej czy przebudować aplikację? Z racji prostoty wygrywa pierwsze rozwiązanie.. (przynajmniej tymczasowo). Wciąż zdecydowana większość aplikacji powstaje (i powinna powstawać) bez martwienia się o infrastrukturę. Wciąż sporej grupie aplikacji skalowanie w górę w zupełności wystarcza, bo nie wyrastają ponad możliwości pojedynczej maszyny.

 

*Tomasz Kozłowski* Przy czym te "mozliwosci pojedynczej maszyny" mozna tez tak naprawde skalowac w nieskonczonosc wiec nie ma limitu.. IBM wypuścił ostatnio ciekawą linię serwerów pod wirtualizację. Pojedynczy taki serwer przyjmuje do 256GB RAM. Cztery takie serwery można spiąć razem, tak że zachowują się jak jedna maszyna (jeden login, itp). Mamy więc już serwer z 1 TB RAM. Twoje phpbb by przemo ma taki ruch zeby sie serwer przytkal? To nie koniec, bo dalej 4 takie serwery można znów spiąć w jeden, itp itd.

 

*p* O ile nie stosujesz takich serwerów u siebie (a nie stosujesz, bo byłoby to po prostu finansowo nieopłacalne), to taka informacja jest jedynie ciekawostką.

 

One wcale nie wychodza az tak drogo jak sie to dobrze policzy ;-)

 

Nic nie mylę, natomiast Ty niepotrzebnie spłycasz dyskusję z

"zwykły" hosting działający w Cloud Infrastruture vs "cloud hosting"

do

Cloud Infrastructure vs serwery dedykowane.

 

Przyznaję - skupiłem się na Cloud Infra vs. dedyk. Choć nie nazwałbym tego spłycaniem..

 

Inna rzecz.. Chyba nie możesz tak jednoznacznie segregować co jest cloud hostingiem, co jest cloud platformą a co jest cloud infrastructure.. Granice między tymi pojęciami są BARDZO płynne, wręcz w wielu miejscach używane zamiennie. A może są gdzieś jakieś odgórnie narzucone definicje o których nie wiem?

 

*Tomasz Kozlowski* Błagam nie nazywajmy tego VPS'em bo technologia która stoi za Cloudem i VPSem jednak mocno się różni

 

*p* Ale od strony funkcjonalnej, dla użytkownika końcowego, to jest tylko VPS z bajerami

 

Tylko te bajery zmieniają diametralnie reguły gry, zasługują więc na osobną kategorię

 

Ok, ale wszystko sie rozbija o koszty. Jezeli roczny koszt Premium VPS (podoba mi sie te okreslenie wiec go bede uzywal), ktory bedzie slabej wydajnosci i raz na jakis czas bedzie mocno zwiekszany bedzie na poziomie ceny kilku serwerow dedykowanych w innej firmie (gdzie mam 24/7/365 dostep do pelnej mocy maszyn) to wybor Premium VPSa nie bedzie juz taki oczywisty. Pamietaj o tym, ze koszt serwera dedykowanego w Polsce (nie mowie tu o jakis pececikach) nie jest juz dosc wysoki (w niektorych firmach) i zbliza sie powoli do kosztow zachodnich.

 

A kto powiedział, że jeden serwer Cloudowy będzie kosztował tyle co kilka zwykłych?

 

O właśnie.. Weźmy taki cloud serwer i dajmy mu parametry takie jak w poprzednim poście (2GB ram, 80GB dysku, 1 rdzeń). Jaką musiałby mieć cenę (za godzinę, miesiąc, rok - jak Ci wygodniej), żeby było "fair" i żebyś rozważał zastosowanie takiego rozwiązania? (pytanie otwarte, do wszystkich

 

Koszt duuuuuuzych serwerow jest wielokrotnie wiekszy niz suma kosztow mniejszych serwerow (np. 2 quady, 24GB ram) przy takiej samej wydajnosci.

Moze sie okazac, ze taniej wyjdzie zaprojektowac skalowalna aplikacje niz kupowac jednego wielkiego Premium VPSa. A dodatkowo jestesmy zupelnie niezalezni pozniej w doborze infrastruktury sprzetowej.

 

Pod warunkiem że masz możliwość zaprojektowania sobie aplikacji.. W sensie pod warunkiem, że dopiero ją budujesz. Bo może się okazać że aplikacja już jest, od lat, a przebudowanie jej lub przeniesienie całej firmy na nowy soft może się okazać bardzo drogim procesem.

 

Nie bardzo rozumiem w jaki sposob jestes niezalezny w doborze infrastruktury sprzetowej? Zawsze jestes niezalezny w tej kwestii tak na prawde

 

Strasznie demonizujesz. Kto Ci w polsce kaze podpisywac cyrograf na 3 lata?

 

Znam sporo takich.. Ale OK.. troche sie zapedzilem.. Tak czy inaczej 24 czy 12 miesiecy to praktycznie standard.. To wciaz BARDZO duzo jesli tak na prawde potrzebujesz tego serwera na pare miesiecy, tygodni czy nawet dni

 

Wcale nie. Skalowalnosc zapewnia mi redundancje, awariami sprzetowymi zajmuje sie DC w przeciagu paru h od zgloszenia.

 

Możesz sobie pozwolić na parę godzin downtime'u z powodu awarii sprzętowej?

 

A jeśli ruch w tym czasie chcesz przerzucić na inne maszyny, to znaczy że przez pozostałe 364dni i 20h w roku te serwery pracują na pół gwizdka, choć płacisz za całość...

 

Ja wiem jak dziala cloud, cennik firmy na v mam pratycznie w glowie (przy roznych konfiguracjach dla roznej wielkosci chmury, itd.). Stad tez z niecierpliwoscia czekam na dobra oferte cenowa (bo nie do konca wierze, ze ona bedzie dobra i bedzie mogla skutecznie konkurowac z serwerami dedykowanymi).

 

Ponawiam więc prośbe - zaproponuj cenę, która Twoim zdaniem byłaby fair.. Myślę, że miło Cię zaskoczę

 

 

 

Cloudy są zbyt skomplikowane aby je zwykły user używał.

 

To zależy tylko i wyłącznie od tego jak je podasz.. Amazon wprowadził zamieszanie, jak w sekcji "oszacuj swój rachunek" wymagał podania ilości Compute Cycles, I/O, itp.

 

Ale tak na prawdę NIC nie stoi na przeszkodzie, żeby podać userowi maszynę, która z punktu widzenia usera będzie się zachowywała DOKŁADNIE tak samo jak zwykły serwer.