Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Ogłoszenie
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
#1 2012-01-28 20:18:08
pink - 
Użytkownik
moosefs
http://www.moosefs.org/about-mfs.html
slyszeli??? przez przypadek trafilem ciekawe.
T430 think-box 4.9-custom x86_64 Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz GenuineIntel GNU/Linux
"Doktor plama i maharadża są pod złotym leszczem." "Człowieka od zwierzęcia odróżnia ciekawość świata. Patrze słucham i wyciągam wnioski."
http://przemyslawmamon.com/
https://www.behance.net/przemyslawmamon
Offline
#2 2012-02-01 21:58:42
whale - Członek DUG
- whale
- Członek DUG
- Skąd: Cambridge
- Zarejestrowany: 2005-09-01
Re: moosefs
Witam,
fajny system plikow nie za szybki ale stabilny glowny problem master server jest single point of failure (przechowuje on wszystkie metadata o plikach). z tego wzgledy zmigrowalem shared storage do glusterfs.
pozdr
Offline
#3 2012-02-08 00:14:07
aNeutrino - Nowy użytkownik
- aNeutrino
- Nowy użytkownik
- Zarejestrowany: 2012-02-07
Re: moosefs
[quote=whale]Witam,
fajny system plikow nie za szybki ale stabilny glowny problem master server jest single point of failure (przechowuje on wszystkie metadata o plikach). z tego wzgledy zmigrowalem shared storage do glusterfs.
pozdr[/quote]
GlusterFS jest zbudowany z samych Single Point of Failure co można przeczytać na ich stronie: [url]http://www.gluster.org/community/documentation/index.php/GlusterFS_Concepts[/url]
[b]to o GlustreFS[/b]: If you lose a single server, you lose access to all the files that are hosted on that server. This is why distribute is typically graphed to the replicate translator.[/quote]
[b]w MooseFS NIE MA Single Point of Failure[/b] - po prostu trzeba samemu sobie napisać srkypt do automatycznego recovery w przypadku awarii servera Master.
Jednakże sam [b]MooseFS [/b]ma pełen mechanizm Prawdziwej replikacji Metadanych do servera typu MetaLogger, których można mieć w sytemie ile się chce.
Jedyne co trzeba zrobić przy awarii Mastera to uczynić Jeden z MetaLoggerów nowym Masterem i wszystkie dane są dostępne.
Po prostu nie jest to automatyczne - co wg mnie jest lepsze bo lubię mieć kontrolę nad nietypową sytuacją.
Używam MooseFS na 4 wielkiech instalacjach - każda z nich ma ponad 400TB rozmiaru - łącznie 2 PetaBajty na 400 serverach (1500 dysków)
Używam go od 5 lat i[b] NIGDY nie straciłem, żadnego pliku.[/b]
Co do prędkości to jest rewelacyjnie - max z sieci 1Gbit (akurat takiej używamy) 100MB/s przy ustawionych Jumbo Frames (MTU 9000)
czas naprawy przy awari pojedynczego dysku 1TB - sekundy - [b]automatyczny i bezstresowy.[/b]
czas naprawy całego serwera - około minuty - tak samo automatyczna
tylko tyle zajmuje pełna odbudowa systemu i w tym czasie [b]wszystko działa.[/b]
Dodatkowo polecam wypróbować funkcje snapszotów na plikach - rewelacja.
I coś co naprawdę uwielbiam w MooseFS jako administrator nękany przez user'ów - przezroczysty kosz - po prostu ustawiłem w systemie, że wszystkie pliki po skasowaniu mają być dostępne w koszu przez okres 24h i jak jakiś user coś sobie skasuje to zawsze mam jego/jej dane pod ręką - PRO.
Wiele ludzi nie docenia MooseFS ale można też troszkę pogoolać i i znaleźć tych co stosują MooseFS od lat proszę:
here you can find the test with 96 DELL machines: [url]http://www.tinkergeek.com/?p=150[/url] and
here another opinion from OpenNebula [url]http://blog.opennebula.org/?p=1512[/url] )
Polecam zdecydowanie MooseFS :)Ostatnio edytowany przez aNeutrino (2012-02-08 00:15:03)
Offline
#4 2013-06-02 21:51:54
scandal36 - Nowy użytkownik
- scandal36
- Nowy użytkownik
- Zarejestrowany: 2013-06-02
Re: moosefs
Witam. Ciesze się, że ktoś wyraża się tak pochlebnie o muss'ie. Planuję wdrożenie systemu "produkcyjnie" w najbliższym czasie, ale mam kilka pytań, na które musze znać odpowiedź zanim to zrobię. Jeśli byłbyś (lub ktokolwiek) tak uprzejmy i mnie oświecił..:)...
Na chwilę obecną używam jako STORAGE do Xen'a Solarisa po Fiberchannel gdzie storage'owe LUNy są widoczne jak urządzenia blokowe (sdx) i maszyny virtualne nie muszą być plikowcami. Rozumiem, że w przypadku MusseFS nie ma takiej opcji więc maszyny virtualne muszą być u mnie plikowcami, co np. przy serwerze pocztowym, czy www daje pliowca > 100GB!! Zatem zmiana nawet 1 BAJTA w takim plikowcu to zmiana całego PLIKU! W związku z tym, chciałbym wiedzieć, czy replikacja kopiuje wciąż > 100GB?? Może jednak jest to rozwiązane inteligentniej i proces replikacji trwa szybko i sprawnie nawet przy dużych plikach...
Jak wygląda odtwarzanie plików ze snapshotu?
Chciałbym zerknąć na skrypcik do auto-recovery?
Z góry dziękuję....
Offline
#5 2013-06-03 04:07:00
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: moosefs
co np. przy serwerze pocztowym, czy www daje pliowca > 100GB!! Zatem zmiana nawet 1 BAJTA w takim plikowcu to zmiana całego PLIKU! W związku z tym, chciałbym wiedzieć, czy replikacja kopiuje wciąż > 100GB??[/quote]
Ja tam jestem lama, ale jak zrobić na serwerze www czy pocztowym plik >100GB i co do niego wsadzić?
Do logów jest logrotate, do maili jest skrzynka maildir, a serwer www nie ma jak i komu zaserwować pliku 100GB, bo na świecie nie ma zbyt wielu pacjentów, którzy takie pliki mogą ściągnąć swoimi rurkami internetowymi w sensownym czasie.
Czasem tak rosną bazy danych, ale wszystkie serwery bazodanowe mają własne mechanizmy replikacji, typu master-slave albo multi-master.
W każdym razie nie zauważyłem na razie neozdrady 10Gbit, a ni nic podobnego.
Jeśli natomiast jakiś Administrator pozwala tworzyć programom takie pliki bez wyraźnej konieczności,
to taki Admin nadaje się na konserwy dla psów i kotów, a nie do serwerów. :DDD
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#6 2013-06-03 12:52:37
jurgensen - Użytkownik
- jurgensen
- Użytkownik
- Skąd: Wrocław
- Zarejestrowany: 2010-01-26
Re: moosefs
Jacekalex, koledze chodziło chyba o to, że plik dysku maszyny wirtualnej będzie miał 100GB.
scandal36, skoro chcesz wykorzystywać to jako przestrzeń dla wirtualek, nie lepiej zostać przy urządzeniach blokowych, wystawiając przestrzeń przez FC lub iSCSI? Jeśli potrzebujesz połączyć przestrzeń z kilku serwerów, zawsze możesz wykorzystać LVM.
Offline
#7 2013-06-03 13:06:37
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: moosefs
Gdyby chodziło o obraz virtualki, to chyba byłby obraz wirtualki, a nie plikowiec.
Poza tym raz juz widziałem serwer www, gdzie acces.log miał ponad 50GB, messages znacznie lepiej, inne logi podobnie, bo jakiś mądrala ileś latek wczesniej nie zanistalował logrotate, aż na Raid 10 z dyziami 1000GB miejsca zabrakło. :D
W dodatku tworzenie 100GB obrazu wirtualki, to też poroniony pomysł, nie wiem, jak VmWare,
ale zarówno Xena jak i KVM podniesiesz z partycji na dysku.
Na obrazie wirtualki masz podwojenie ryzyka awarii, jeden system plików na drugim, i solidny narzut na dysk, kiedy masz na dysku obraz, a na tym obrazie partycje wirtualki.
Samo pojęcie 100GB i nie może się zmienić jeden bajt - oznacza, że jeden bad-sektor wywali ci cały plik?
Czy widzial ktoś dyski, które sa całkowicie odporne na błędy mechaniczne, elektryczne, i nigdy nie będą miały żadnego bad-sektora?
Bo ja nigdy nie slyszalem o podobnych cudach nawet w kosciele na bożym ciele, nie wspominając o realnym świecie. :D
Chyba, że ktoś na serwery ładuje Virtualboxa..... ;)
Ostatnio edytowany przez Jacekalex (2013-06-03 13:20:39)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#8 2013-06-03 14:24:42
scandal36 - Nowy użytkownik
- scandal36
- Nowy użytkownik
- Zarejestrowany: 2013-06-02
Re: moosefs
Witam i dziękuję za odpowiedzi.
@ Jacekalex - dokładnie jak pisał kolega jurgensen - VM XEN może zakładac maszyny wirtualne na fizycznym urządzeniu blokowym (np. dysku, storage'u po FC), albo w postaci pliku. W drugim przypadku plik jest duży po serwer pocztowy IMAP ma wiele kont i wiele danych, co daje pliki wielkości > 100GB. Nie ma z tym problemu w pracy a odtworzenie czy backup takiej maszyny jest bardzo szybki. Jak na razie używam Sorage po FiberChanel i LVM'y, ale przy rosnącej liczbie maszyn i plików musze wdrożyć system rozproszony. Nazywanie jakiegoś pomysłu "poronionym" tez może być poronione :). Jak piszesz "Ja tam jestem lama", ale ja nie jestem i wiem, co piszę. Tak czy owak - dziękuję za krytykę
@ jurgensen - LVM i FC jest super ale np. snapshoty LVM w odtwarzaniu są o wiele bardziej toporne niż w MooseFS.
Generalnie uzyskałem juz informację od MoosFS jak dział to przy dużych plikach. Jeśli miałeś do czynienia z BACULA (czy innym systemem backupu) to zobaczysz że incremental działa na poziomie plików (np. przy modyfikacji 10GB pliku incremental i tak bedzie miał 10GB) a nie chunków (tu replikowane są zmieniające się bloki). Dlatego z ta informacją moge już śmiało testować wdrożenie.
Offline
#9 2013-06-03 15:59:30
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/urandom
- Zarejestrowany: 2008-01-07
Re: moosefs
W drugim przypadku plik jest duży po serwer pocztowy IMAP ma wiele kont i wiele danych, co daje pliki wielkości > 100GB.[/quote]
Szaleństwo ;)
Jak ja bym to zrobił?
Serwer SMTP doręcza poczte poprzez dovecot-lda lub dovecot-lmtp, a tam:Kod:
dsync over TCP connections (v2.2+)[url]http://wiki2.dovecot.org/Replication[/url]
Do tego replikacja bazy danych z użytkownikami, oraz bazy z ustawieniami spamassasina, filtrami bayesa itp.
W ten sposób, jak jeden serwer diabli wezmą, nie traci się ani jednego maila, a użytkownicy mają cały czas dostęp do poczty, wystarczy zatrudnić np ucarpa, albo ustawić kilka serwerów pocztowych w dns.
WWW? całe strony składają się praktycznie z plików graficznych, multimedialnych, i bazy danych, do tego drobiazgi, czyli php, css, js, txt czy cgi.
Tu też lepiej nie tworzyć takich obrazów do kopiowania w calości, tylko np DRBD, czy wysmażyć coś korzystając z mechanizmu inotify czy dnotify (lub podobnego) do synchronizacji online.
Bo kopiowanie przez sieć 100GB w jednym pliku, żeby się ani jeden bajt nie zmienił, to jest pole minowe, nawet w najzwyklejszej sieci lan nie warto ryzykować.
Jak się kopiuje np film mający kilka GB, to błąd obejmujący np 2kB danych - to jedna zgubiona klatka, można wytrzymać, jak to wygląda w przypadku maszyny wirtualnej, szkoda komentować.
Pomijając milczeniem kwestie dostępności maszyny wirtualnej w czasie kopiowania jej obrazu, i potem sprawdzania sum kontrolnych pliku, który ma 100GB.
Nawet przy łączu 10Gbit kopiowanie takiego diabelstwa, to jest kawał czasu, a po obu stronach odczyt i zapis to jest kosmiczna robota.
Czy może cały VM do backupu trzeba wyłączyć, skopiować, porównać sumy kontrolne, i dopiero włączyć?
I to się ma nazywać wysoka dostępność - cecha podstawowa każdego serwera WWW, poczty, jabbera, voipa, czy innej usługi sieciowej?
Jeżeli jakaś usługa musi spełniać zasady bezpieczeństwa i dostępności, to przełączenie miedzy maszyną podstawową i zapasową musi trwać najwyżej minutę, a nie 2 godziny. :D
Pozdrawiam
;-)
Pozdrawiam
;-)Ostatnio edytowany przez Jacekalex (2013-06-03 16:15:42)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#10 2013-06-03 19:50:56
scandal36 - Nowy użytkownik
- scandal36
- Nowy użytkownik
- Zarejestrowany: 2013-06-02
Re: moosefs
Dziękuję za wyjaśnienia. Oczywiście duzo w tym racji niemniej jak już napisałem w MooseFS zmiany sa na chunkach i wielkość pliku nie ma znaczenia. Dokładnie tak samo jest z problemem dostepności maszyny online - nie ma takiego problemu. Niemniej przeanalizuję pomysły, które opisałeś i wezmę sobie rady "do serca" na przyszłość. Wiedzy nigdy dość. Pozdrawiam.
Offline
Informacje debugowania
| Time (s) | Query |
|---|---|
| 0.00014 | SET CHARSET latin2 |
| 0.00007 | SET NAMES latin2 |
| 0.00121 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.218.188.95' WHERE u.id=1 |
| 0.00109 | UPDATE punbb_online SET logged=1716187611 WHERE ident='18.218.188.95' |
| 0.00062 | SELECT * FROM punbb_online WHERE logged<1716187311 |
| 0.00084 | DELETE FROM punbb_online WHERE ident='54.36.149.71' |
| 0.00090 | SELECT topic_id FROM punbb_posts WHERE id=233979 |
| 0.00254 | SELECT id FROM punbb_posts WHERE topic_id=20531 ORDER BY posted |
| 0.00064 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=20531 AND t.moved_to IS NULL |
| 0.00008 | SELECT search_for, replace_with FROM punbb_censoring |
| 0.00137 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=20531 ORDER BY p.id LIMIT 0,25 |
| 0.00092 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=20531 |
| Total query time: 0.01042 s | |