On 2012-04-19, Andrzej Lawa <a...@l...SPAM_PRECZ.com> wrote:

[...]

>> Niby fajne, ale nadal nie załatwia problemu redundancji.
> Jak nie jak tak?

No nie. Z samej składni widać że jest source - target, a nie
source - multiple-targets.

>> No i to jest takie "zrób to sam".
> No i? Zapłacisz komuś, to ktoś ci to zrobi ;)

No właśnie. A z rozwiązaniami w cloud zrobię to po prostu wygodniej
i taniej.

>> A i niespecjalnie widzę rdiff-backup w sytuacji odzyskiwania danych z bazy
>> sql. Pewnie możliwe, ale nietrywialne, a w takich sytuacjach (awarie),
>
> Trywialne. Przed rdiff-backup odpalasz mysqldump - i pięknie robi się
> kopia różnicowa bazy danych.

O jeny. Ale komplikacje. I tak dla każdego obsługiwanego rdbms osobno
dłubać ścieżkę i sposób backupu? :)

--
Wojciech Bańcer
p...@p...pl

do góry

>
>> Trywialne. Przed rdiff-backup odpalasz mysqldump - i pięknie robi się
>> kopia różnicowa bazy danych.
>
> O jeny. Ale komplikacje. I tak dla każdego obsługiwanego rdbms osobno
> dłubać ścieżkę i sposób backupu? :)

A chmura to jak niby to robi ?

do góry

On 2012-04-19, John Kołalsky <j...@k...invalid> wrote:

[...]

>> O jeny. Ale komplikacje. I tak dla każdego obsługiwanego rdbms osobno
>> dłubać ścieżkę i sposób backupu? :)
> A chmura to jak niby to robi ?

Ta z której korzystam? Coś innego.

--
Wojciech Bańcer
p...@p...pl

do góry

Użytkownik "Wojciech Bancer" <p...@p...pl> napisał w wiadomości
news:slrnjooi55.7on.proteus@pl-test.org...
> On 2012-04-16, qwerty <q...@p...fm> wrote:
>
> [...]
>
>>> No i pod adresem jest np. WiFi z podpiętymi 10-20 urządzeniami.
>>> To kto korzystał?
>>
>> Logi
>
> Co "Logi"? Śniło Ci się, że domowe routerki je przechowują? :)
>
>
Ponoć lepiej jak kilka osób się przyzna że korzystało.
Wtedy umarzają.
Jak nikt się nie przyzna - to drążą i znajdują...

Feromon

do góry

W dniu 2012-04-20 01:57, Feromon pisze:

>>> Logi
>>
>> Co "Logi"? Śniło Ci się, że domowe routerki je przechowują? :)
>>
>>
> Ponoć lepiej jak kilka osób się przyzna że korzystało.
> Wtedy umarzają.
> Jak nikt się nie przyzna - to drążą i znajdują...

"Ponoć" robi wielką różnicę. ;)

http://pl.wikipedia.org/wiki/Dylemat_wi%C4%99%C5%BAn
ia





--
Dziękuję. Pozdrawiam Ten Maruda

do góry

Dnia Thu, 19 Apr 2012 09:34:37 +0200, Ajgor napisał(a):

> Dzialalo to tak, ze wyslali kilkadziesiat tysiecy falszywych e-maili do
> klientow banku, w ktorych...
> prosili o zamiane hasla ze wzgledow bezpieczenstwa :) W mailu byl podany
> adres do zmiany hasla.

Przecież to klasyczny phising, a nie żadne włamanie na stronę banku.
Takich historii są dziesiątki. A to jakiś bank, a to Allegro, a to jeszcze
ktoś inny na tyle duży, by się opłacało w to bawić.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

Dnia Thu, 19 Apr 2012 14:09:08 +0200, Wojciech Bancer napisał(a):

>>> Może po prostu nie rozumiesz czym jest chmura? :)
>>
>> Jest głównie nowomową na system rozproszony w architekturze klient-serwer.
>
> Czyli jednak nie do końca rozumiesz. :)

Zdefiniuj zatem swoją "chmurę". Jak dla mnie jest to tylko popularna nazwa
na powyższą kombinację.

>> Niedługo byle hosting z load-balancingiem będzie "chmurą". Ale przyjdzie
>> nowa moda, przyjdą nowe buzzwords.
>
> Nie. Nie będzie.

Będzie, będzie. Kilkanaście lat temu wszystko było e-. Później wszystko
musiało być m-. Teraz wszystko musi być w chmurze (i byle hosting się
naciąga do tego pojęcia), a najlepiej gdyby dodatkowo było startupem i "w
erze post-PC". Za kilka lat pewnie odkryciem będzie moc obliczeniowa na
biurku i na to znajdą jakieś modne słowo.

> To jest skutek właśnie tego że ludzie nie wiedzą co to jest chmura. Traktują to
jako
> pudełko które "samo się". Nic "samo się", chmura to narzędzie które pozwala
stworzyć
> tanio efektywny i sprawny system który jest odporny. Narzędzie które trzeba
rozumieć.

Jeśli "chmura" daje Ci przestrzeń dyskową, po czym szlag ją trafia z winy
dostawcy, to co tu jest do rozumienia? :) Zostaje tylko liczyć na backupy,
czy to własne, czy dostawcy.

> Wyobrażasz sobie (bez chmury) możliwość cofnięcia się z danymi do dowolnego
> punktu z krokiem 15 minut, w ciągu ostatnich 3 dni, rozlokowania tego w dwóch
> niezależnych geolokalizacyjnie serwerowniach?

Dokładnie tak, jak napisał Andrzej, z dokładnością do wersji użytego
narzędzia.

> Da się, ale jaki byłby koszt:
> - opracownaia informatycznego takiej struktury

Koszt sklejenia kilku skryptów do rsynca raczej nie byłby przerażający :)

> - samej struktury (jeśliby przyjąć tradycyjny, dzierżawiony model)

To zależy od tego, na co się decydujesz. Zapewne wydzielony kawałek dysku
będzie dużo tańszy, niż hosting, nie mówiąc o dzierżawie serwera.

> - koszt zespołu IT monitorującego to
> ? :-)

"Tu masz logi, czytaj" ;)

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

On 2012-04-20, Borys Pogoreło <b...@p...edu.leszno> wrote:

[...]

>>> Jest głównie nowomową na system rozproszony w architekturze klient-serwer.
>> Czyli jednak nie do końca rozumiesz. :)
>
> Zdefiniuj zatem swoją "chmurę". Jak dla mnie jest to tylko popularna nazwa
> na powyższą kombinację.

Zacznijmy od tego, że nie musi być to architektura "klient-serwer". A kluczową
i istotną różnicą jest to, że cc to jest też dodatkowa warstwa abstrakcji pomiędzy
sprzętem, a Twoją usługą. I w przeciwieństwie do tradycyjnych VPSów, ta warstwa
abstrakcji jest przeznaczona do działania w środowisku rozproszonym.

Bazując na tym (wirtualizacji) i rozwiązaniach tam dostępnych usługa może być
rozbudowana do postaci umożliwiającej odzyskanie/postawienie kopii środowiska
w czasie liczonym w minutach, a nie w godzinach/dniach. Można też osiągnąć
poziom elastyczności i skalowalności jaki jest (w praktyce) nie do osiągnięcia
innymi metodami.

>>> Niedługo byle hosting z load-balancingiem będzie "chmurą". Ale przyjdzie
>>> nowa moda, przyjdą nowe buzzwords.
>>
>> Nie. Nie będzie.
>
> Będzie, będzie. Kilkanaście lat temu wszystko było e-. Później wszystko
> musiało być m-.

Nie będzie, bo "byle-hosting z load balancingiem" nie zapewnia tego o czym pisałem
wcześniej. Oczywiście nie przeczę, że marketingowcy mogą nadużywać tego pojęcia.

>> To jest skutek właśnie tego że ludzie nie wiedzą co to jest chmura. Traktują to
jako
>> pudełko które "samo się". Nic "samo się", chmura to narzędzie które pozwala
stworzyć
>> tanio efektywny i sprawny system który jest odporny. Narzędzie które trzeba
rozumieć.
>
> Jeśli "chmura" daje Ci przestrzeń dyskową, po czym szlag ją trafia z winy
> dostawcy, to co tu jest do rozumienia? :) Zostaje tylko liczyć na backupy,
> czy to własne, czy dostawcy.

Ale "chmura" nie gwarantuje że się nic nie stanie. Chmura drastycznie zmniejsza
ryzyko błędów związanych z awarią konkretnej jednostki sprzętowej. Tylko tyle
i aż tyle (nie licząc usług dodanych związanych z warstwą wirtualizacji,
bo tego co platforma wirtualna w architekturze rozproszonej daje - nie osiągniesz
prostymi dedyki + load balancer).

>> Wyobrażasz sobie (bez chmury) możliwość cofnięcia się z danymi do dowolnego
>> punktu z krokiem 15 minut, w ciągu ostatnich 3 dni, rozlokowania tego w dwóch
>> niezależnych geolokalizacyjnie serwerowniach?
>
> Dokładnie tak, jak napisał Andrzej, z dokładnością do wersji użytego
> narzędzia.

Nie, bo u podstaw działania leży hardware-fault tolerance, a to jest
niemożliwe do osiągnięcia bez dodatkowej warstwy abstrakcji.

>> Da się, ale jaki byłby koszt:
>> - opracownaia informatycznego takiej struktury
>
> Koszt sklejenia kilku skryptów do rsynca raczej nie byłby przerażający :)
>
>> - samej struktury (jeśliby przyjąć tradycyjny, dzierżawiony model)
>
> To zależy od tego, na co się decydujesz. Zapewne wydzielony kawałek dysku
> będzie dużo tańszy, niż hosting, nie mówiąc o dzierżawie serwera.
>
>> - koszt zespołu IT monitorującego to
>> ? :-)
>
> "Tu masz logi, czytaj" ;)

No i po tym to już mam pewność, że nie do końca rozumiesz czym jest
chmura. :)

--
Wojciech Bańcer
p...@p...pl

do góry

W dniu 19.04.2012 15:26, Wojciech Bancer pisze:

>>> Niby fajne, ale nadal nie załatwia problemu redundancji.
>> Jak nie jak tak?
>
> No nie. Z samej składni widać że jest source - target, a nie
> source - multiple-targets.

Masz oryginał i kopię. Redundancja? Redundancja!

>>> No i to jest takie "zrób to sam".
>> No i? Zapłacisz komuś, to ktoś ci to zrobi ;)
>
> No właśnie. A z rozwiązaniami w cloud zrobię to po prostu wygodniej
> i taniej.

Pytanie, czy bezpieczniej.

>>> A i niespecjalnie widzę rdiff-backup w sytuacji odzyskiwania danych z bazy
>>> sql. Pewnie możliwe, ale nietrywialne, a w takich sytuacjach (awarie),
>>
>> Trywialne. Przed rdiff-backup odpalasz mysqldump - i pięknie robi się
>> kopia różnicowa bazy danych.
>
> O jeny. Ale komplikacje. I tak dla każdego obsługiwanego rdbms osobno
> dłubać ścieżkę i sposób backupu? :)

A jak proponujesz inaczej mieć redundancję bazy danych?

Całą bazę danych trzymać wyłącznie "gdzieś w chmurze"?

do góry

On 2012-04-23, Andrzej Lawa <a...@l...SPAM_PRECZ.com> wrote:

[...]

>> No nie. Z samej składni widać że jest source - target, a nie
>> source - multiple-targets.
> Masz oryginał i kopię. Redundancja? Redundancja!

:-)

>>> Trywialne. Przed rdiff-backup odpalasz mysqldump - i pięknie robi się
>>> kopia różnicowa bazy danych.
>> O jeny. Ale komplikacje. I tak dla każdego obsługiwanego rdbms osobno
>> dłubać ścieżkę i sposób backupu? :)
> A jak proponujesz inaczej mieć redundancję bazy danych?
> Całą bazę danych trzymać wyłącznie "gdzieś w chmurze"?

Ależ ja nie proponuję. Ja *mam* i używam. Ale ja wolę wymyślać nowe rzeczy
niż ciągle wynajdować "koło" tylko dlatego że ktoś za sposób na swoje "koło"
chce pieniądze.

--
Wojciech Bańcer
p...@p...pl

do góry