abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
dnes 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (75%)
 (13%)
Celkem 226 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

    AToL: Distributed Replicated Block Device

    22.6.2011 14:10 | Přečteno: 1950× | Linux | poslední úprava: 22.6.2011 14:09

    Autor: Martin Skala
    Nasledovný príspevok je študentskou prácou, ktorá vznikla v rámci predmetu Advanced Topics of Linux Administration. Predmet je vypisovaný na Fakulte informatiky MU v spolupráci so spoločnosťou Red Hat Czech. Vyučovacím jazykom je angličtina a preto je v nej aj nasledovný príspevok. Komentáre k obsahu príspevku sú vítané v ľubovoľnom zrozumiteľnom jazyku.

    Contents


    What is this article about?

    This article introduces one of many solutions for ensuring a high availability (HA). The solution is called DRBD (Distributed Replicated Block Device). In fact, the main goal of the article is not a presentation of advanced configuration cases but introduction of DRBD, description of its most important features and summarization of basic information. In the conclusion section I picked up the most interesting features based on DRBD's development roadmap, which are planned in the following versions, and selected some interesting statistics about DRBD usage. In this article I'll refer to DRBD version 8.3.10 unless stated otherwise.


    What is DRBD?

    DRBD (Distributed Replicated Block Device) is a software-based open source replicated storage solution for mirroring the content of block devices between servers via an assigned network. That's why you do not need to have any specialized hardware. It's actually a building block to form high availability (HA) clusters and it could be treated as a network-based RAID-1. Project DRBD enables data mirroring on hard disks, partitions and logical volumes and it works transparently in real-time synchronous or asynchronous mode over different types of replication transports. More information about synchronous and asynchronous replicating modes can be found in section 4.3.

    The term DRBD refers to a logical block device and the software which breaks down into a kernel module and management userspace applications. Since the kernel module uses a driver for a virtual block device, DRBD is located as near the bottom of a system's I/O stack as possible (see figure 1). Such a virtual block device can be actually used as a PV for LVM.

    At the beginning the focus was on single-primary mode but now it also supports off-site nodes and dual-primary mode (i.e. running of two active nodes at the same time). At the end of 2009 DRBD got merged into Linux kernel version 2.6.33.

    Figure 1: DRBD's position within the Linux I/O stack
    Image drbd_uc3


    How was it with DRBD?

    The core of DRBD has been developed on 8th December 1999 by Philipp Reisner as a part of his Master's thesis at the Vienna University of Technology in Austria. This early version of DRBD was intended for storing email messages in a redundant way.

    In November 2001 Reisner co-founded company LINBIT which was focused on advancing the development of DRBD and Linux HA for enterprise sector.

    Next important event was the join of Lars Ellenberg into LINBIT in May 2005. Lars impressed Phil so much that both led the R&D team.

    Next major step was the release of DRBD version 8 in January 2007. This version broke previous performance barriers and introduced dual-primary clustering capability which allowed simultaneous write access from two cluster nodes.

    LINBIT USA, LLC was founded in 2008. It was primarily focused on integration services in North, Central and South America, development, consultancy and 24/7 support. In the same year LINBIT has made a formerly commercially licensed add-on DRBD+ open-source. The add-on was merged into DRBD 8.3 and it offered stacked device support, huge device support for devices larger than 4 TB, checksum-based resync and three and four node clustering support (see [2, p. 46-47, 60-63]).

    As was already mentioned, DRBD got merged into Linux kernel version 2.6.33 at the end of 2009.


    How does it work?

    In this section I'll refer to DRBD version 8.3.10 and outline its primary features, capabilities and objectives.


    Features

    DRBD supports large single block devices that reach up to one petabyte on 64bit architectures. It also offers two main operation modes which are single-primary and dual-primary mode. In single-primary mode it's possible to use any conventional filesystem (e.g. ext3, ext4, ReiserFS or XFS) but in dual-primary we have to choose a distributed (cluster-aware) filesystem like GFS2 or OCFS2.

    In order to add redundancy it facilitates incorporation into existing infrastructure by many integration scripts (e.g. for Heartbeat, Red Hat Cluster except GUI, Xen and LVM). Speaking of LVM, DRBD works with both physical volumes (PV) and logical volumes (LV) and it also supports LV snapshots. Another supported project is Enterprise Volume Management System (EVMS) which is a single unified system for handling all of storage management tasks and allows use of following filesystems: Ext2/3, JFS, ReiserFS, XFS, Swap, OCFS2, NTFS and FAT.

    If we need to secure DRBD's transport channels and stored data we can transparently use IPSec or VPN and standard OS block device encryption. Peer authentication during an initial connection can be achieved by shared secret. When necessary, it's possible to do an online data integrity verification (e.g. as soon as a secondary node is promoted after failure of the primary node).

    DRBD deployment is resistant to (and allow recovery of) several types of failure (e.g. the node, the storage device or the network) with fast and effective resynchronization (resync). After complete failure, DRBD automatically detects the most up-to-date data and the following resync transfers only those blocks1 which were modified during the outage and could be under bandwidth control. Moreover, sync can be based on checksums which make synchronization even faster and independent of the device size. Next feature is an online verification of device which enables us to do a block-by-block data integrity check of the nodes very efficiently (considering network bandwidth). Because all of this it could noticeably impact CPU utilization and load.

    Administrator can also appreciate customization of masking local I/O errors. Masking errors has three basic strategies. Detach strategy, which is the recommended one and usually used, causes that when lower-level I/O error occur, the node drops its backing device and continues in diskless mode. Other strategies are not described here and can be found in documentation[2, p. 39-40]. Events like outage of primary node (pri-lost) and many others could be managed through event handlers[2, p. 126].

    Fencing at resource level is provided by scripts. Scripts use Pacemaker's constraints and should prevent Pacemaker from promoting a DRBD Master/Slave resource when its DRBD replication link has been interrupted. This keeps Pacemaker from starting a service with outdated data and causing an unwanted "time warp" in the process[2, p. 57]. It's configurable with fencing directive in resource context in DRBD's configuration file.

    As a replication transport it's possible to use TCP/IP over IPv4/IPv6, SuperSockets over Dolphin NICs or SDP over Infiniband. Mirroring over long distances and high throughput internet links often requires active bandwidth management which is also supported by DRBD. This bandwidth management optionally includes complete suspension in case the bandwidth is not sufficient.

    DRBD Proxy is commercial facility or mechanism to buffer ongoing replication data from primary node. The commercial licence purchase and technical support is provided directly by LINBIT. This technique can be used for long distance replications, helps to mitigate write bursts and time spent in blocking state while a socket output buffer is full, and optionally compress or decompress the data it forwards. DRBD Proxy buffer is configurable and limited only by the address room size and available physical memory.


    Configuration and tools

    After a brief overview of the features it's time to introduce DRBD's components and management tools. The configuration file drbd.conf is in default located in directory /etc/. The configuration for each resource must match on each node.

    Since DRBD contains lots of management tools and scripts, let's highlight the most important[2, p. 123-161]:

    drbdadm
    - is an administration tool which works as a front-end application for both drbdsetup and drbdmeta and hands off instructions for actual command execution to either of them. It obtains all DRBD configuration parameters from configuration file /etc/drbd.conf and supports dry-run mode.
    drbdsetup
    - is a low-level tool to configure the loaded DRBD kernel module. It facilitates association of DRBD devices with their backing devices, allows set up DRBD device pairs to mirror their backing devices, and is used to inspect the config of running DRBD devices. This tool is also used by data disk and DRBD's scripts to communicate with the device driver.
    drbdmeta
    - is a management tool for DRBD's meta data which is not usually used directly but through drbdadm. It's used to create, dump, restore and modify DRBD's meta data structures for resources that are detached from its backing storage or currently down.
    dopd
    - is a daemon for services to prevent access to outdated data.
    drbd-overview
    - shows status of DRBD's currently configured resources. Other way to check the real-time status information is to look at virtual file /proc/drbd.
    /etc/init.d/drbd
    - is an init script to automatically enable resources configured in /etc/drbd.conf upon system startup or to manage DRBD's state.


    LINBIT has developed a graphical user interface called DRBD Management Console (DRBD MC). The DRBD MC is a Java application that eases the burden of managing DRBD and Pacemaker/Corosync or Heartbeat-based cluster systems (cf. Figure 2). The application is designed for administrators2 and developers and does not require any agent or client daemon on the cluster nodes. It uses ssh access, as you do when you work with your servers[3].

    DRBD MC has a wizard driven installation/update of DRBD/Pacemaker, has a wizard driven creation of Heartbeat configuration file ha.cf, presents complete DRBD, NICs and block devices status, allows creation of a new DRBD resources, views in text console all commands that DRBD MC issues, etc. More information can be found in [3].

    Figure 2: Screenshot from DRBD Management Console
    Image drbd-mc2


    Replication modes

    Protocol A
    is an asynchronous replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has occurred, and the replication packet has been placed in the local TCP send buffer. In the event of forced fail-over, data loss may occur. The data on the standby node is consistent after fail-over, however, the most recent updates performed prior to the crash could be lost.
    Protocol B
    is a semi-synchronous (memory synchronization) replication protocol. Local write operations on the primary node are considered completed as soon as the local disk write has occurred, and the replication packet has reached the peer node. Normally, no writes are lost in case of forced fail-over. However, in the event of simultaneous power failure on both nodes and concurrent, irreversible destruction of the primary's data store, the most recent writes completed on the primary may be lost.
    Protocol C
    is a synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write have been confirmed. As a result, loss of a single node is guaranteed not to lead to any data loss. Data loss is, of course, inevitable even with this replication protocol if both nodes (or their storage subsystems) are irreversibly destroyed at the same time [2, p.5-6].


    Dual-primary mode

    In dual-primary mode, any resource is, at any given time, is in the primary role on both cluster nodes. That's why this mode requires use of a shared cluster file system such as GFS or OCFS2 that supports a distributed lock management.

    For load-balancing clusters which require concurrent data access from more nodes at the same time is dual-primary mode the preferred approach. By default, this mode is disabled and must be explicitly enabled in the configuration file. However, this solution is more sensitive to replication network failure.

     
    resource resource_name {
      net {
        allow-two-primaries;
      }
      ...
      startup {
        become-primary-on both;
      }
      ...
    }
    

    Other approach:


    Three-way replication

    DRBR since version 8.3.0 supports three node setup. In this configuration DRBD adds a third node to an existing 2-node cluster setup and replicates data to that node, where it can be used for backup and disaster recovery purposes. To enable three-way replication we need to add another stacked DRBD resource on top of the existing resource holding our production data (see figure 3).

    The stacked resource is usually replicated using asynchronous replication (Protocol A, cf. section 4.3), whereas the production data would usually use synchronous replication (Protocol C). Selection of protocol A is not required for stacked resources. The choice depends on its application and basically you can select any of DRBD's replication protocols. It's possible to use three-way replication permanently, where the third node is being kept updated with data from the production cluster, or it may be also employed on demand, where the production cluster is normally disconnected from the backup site and site-to-site synchronization is performed on a regular basis, for example by running a nightly cron job.

    When a stacked device is used, this device becomes the active one that we will mount and use. The device meta data will be stored twice on the underlying DRBD device and the stacked DRBD device. It's always necessary for the stacked device to use internal meta data on it.

     
    resource r0 {
       protocol C;
       on node1 {
          device /dev/drbd0;
          disk /dev/sda6;
          address 10.0.0.1:7788;
          meta-disk internal;
       }
       on node2 {
          device /dev/drbd0;
          disk /dev/sda6;
          address 10.0.0.2:7788;
          meta-disk internal;
       }
    }
    resource r0-U {
       protocol A;
       stacked-on-top-of r0 {
          device /dev/drbd10;
          address 147.251.53.40:7788;
       }
       on node3 {
          device /dev/drbd10;   
          disk /dev/hda6;
          address 147.251.53.41:7788; # Public IP of the backup node
          meta-disk internal;
       }
    }
    

    You can see that the keyword stacked-on-top-of replaces one of the on section normally found in 2-node cluster configuration. The keyword informs DRBD that a resource in which this keyword is included is a stacked resource. Do not use stacked-on-top-of in a lower-level resource. More information about how to maintain or enable stacked resources can be found in [2, p. 46-47]

    Figure 3: DRBD resource stacking
    Image drbd-resource-stacking


    Four-way replication

    Suppose we have three DRBD resources (two unstacked and one stacked) in use. In order to achieve 4-way storage redundancy, it will require two two-node Pacemaker clusters. For this configuration it means that up to three nodes can fail while still providing service availability. Since the configuration starts to be more complex, please see configuration, illustration and more information in [2, p. 60-63].


    Split brain and data recovery

    Split brain is a situation where both nodes are switched to primary role while disconnected due to temporary failure of all network links between cluster nodes or due to intervention by a cluster management software or human error. It's potentially harmful state, because modifications to the data might have been made on either node without its replication to the peer. You can imagine this situation as two diverging sets of data that have been created but which cannot be trivially merged.

    DRBD allows automatic operator notification (by email or some other means4) when it detects split brain. The split brain victim (the node whose modifications will be discarded) is not subjected to full device synchronization. Instead, it has its local modifications rolled back, and any modification made on the split brain survivor propagates to the victim.

    Automatic split brain recovery has some configurable policies. DRBD applies its split brain recovery procedures based on the number of nodes in primary role at the time split brain is detected. In the resource's net configuration section, DRBD examines keywords after-sb-Npri where N is number zero, one or two (e.g. after-sb-1pri). Each of the keywords indicates situation when split brain has just been detected and the resource is (at this time) in primary role on two nodes, one node or none. The keywords use specific actions that indicate how the split brain should be solved in such a situation (cf. configuration fragment in File 2). Action's overview can be found in [2, p. 45]. Automatic split brain recovery is disabled by default from DRBD 8 and newer.

    The counterpart to automatic data recovery after a split brain is a manual data recovery. If automatic split brain recovery is not configured while DRBD detects that both nodes are (or were at some point, while disconnected) in the primary role, it immediately tears down the replication connection.

    At this point you have to manually intervene by selecting one node whose modifications will be discarded. This intervention is made with the following commands:

     
    # at the split brain victim 
    drbdadm secondary resource
    drbdadm -- --discard-my-data connect resource 
     
    # at the split brain survivor
    drbdadm connect resource
    

    After reconnection, your split brain victim immediately changes its connection state to SyncTarget, and has its modifications overwritten by the remaining primary node. Once resynchronization has completed, the split brain is considered resolved and the two nodes form a fully consistent, redundant replicated storage system again[2, p. 53-54].




    Outage or failure

    At the beginning of this section, it's important to make clear the difference between inconsistent and outdated data.

    Inconsistent data is data that cannot be expected to be accessible and useful in any manner. The prime example for this is data on a node that is currently the target of an on-going synchronization. Data on such a node is part obsolete, part up to date, and impossible to identify as either.

    On the other hand, outdated data is data on a secondary node that is consistent, but no longer in sync with the primary node. This would occur in any interruption (temporary or permanent) of the replication link. Data on an outdated, disconnected secondary node is expected to be clean, but it reflects a state of the peer node which might be obsolete. In order to avoid services using outdated data, DRBD disallows promoting a resource that is in the outdated state. DRBD allows an external application to outdate a secondary node as soon as a network interruption occurs. DRBD will then refuse to switch the node to primary role and this prevents applications from using the outdated data. Whenever an outdated resource has its replication link re-established, its outdated flag is automatically cleared and then follows background synchronization[2, p. 10].


    Troubleshooting and recovery after outage can be separated into following outage categories5:

    Node
    - in this case automatic resynchronization of the temporarily unavailable node to the latest version of the data will occur in background without interfering with the running of service. This will also work if the surviving node role was changed meanwhile the peer was down. If both nodes are taken down due to a complete power outage, DRBD will detect which of the nodes was down longer, and will do the resynchronization in the right direction.
    Storage subsystem
    - the failure of a disk on the active node can be masked6 and if the disk can be replaced without shutting down the machine, it can be then reattached to DRBD and it will resynchronize the data as needed.
    Replication network
    - just described automatic recovery mechanism works when temporary failure of the replication network occurs. DRBD will establish the connection again and do the necessary resynchronization automatically.
    All network links
    - in the event of split brain, DRBD supports you with several recovery options (cf. section 4.7).


    Deployment

    DRBD can be used in various types of deployment and configuration. One of the typical situations (when we can choose DRBD) is a load-balancing or high availability configuration. To be able to fully implement this configuration in practice, it will require more than just a network mirroring. For that reason DRBD facilitates integration with Pacemaker clusters, Heartbeat clusters, Red Hat Cluster Suite and/or Xen. For more information how to integrate DRBD into mentioned systems see [2, p. 56-101].

    Services that can utilize value of DRBD are: file services (e.g. SMB, NFS), databases (e.g. MySQL, PgSQL), authentication services (e.g. LDAP), network services (e.g. DHCP) and many others7.

    On the other hand, DRBD is Linux solution only and might not be suitable for every application e.g. when cross-site replication depends on available bandwidth and write rate or when we need to establish mirroring between more than four nodes.


    What is the conclusion?

    If you read the article to this point, you should have the minimal knowledge about what DRBD is, what its basic principals are, what it offers and where you can find more information about those parts that are interesting for you.

    In my opinion, DRBD project is very mature piece of software with lot of features which can be otherwise achieved by e.g. an expensive hardware or with a commercial software solution. Since DRBD is an open source with very large community and active development, it might be a good option for those who want a shared storage without special shared hardware, scalable and stable deployment and/or cheap HA solution for many applications. Sure, DRBD is better but not faster or cheaper than a single server and, on the other hand, it's cheaper but (might) not (be) better than a replicated SAN or NAS. I already tried to show on examples in section 4.9 that DRBD is not suitable for every kind of application related to network mirroring.

    Let talk numbers. In the last twelve months (June 2010 - May 2011) it was recorded over 76 500 installations or updates8 of DRBD and almost 118 000 installations in total based on sum of current usage per all installed DRBD's deployments9. I'll finish this paragraph with something I read in user guide and many tutorials and you should keep that in your mind: "Replication is not a replacement for backups!"


    Roadmap

    In the following list is a basic overview of some selected features which should be implemented in next DRBD's releases and might be interesting for you.


    Resources and additional information

    Bibliography

    1
    Andrew Beekhof.
    Clusters From Scratch.
    Online, 2010.
    Available at http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf.
    2
    Florian Hass, Philipp Reisner, and Lars Ellenberg.
    The DRBD User's Guide.
    LINBIT HA Solutions GmbH, 2011.
    Available at http://www.linbit.com/fileadmin/tech-guides/drbd-users-guide-1.3.4.pdf.
    3
    Rasto Levrinc and LINBIT HA-Solutions GmbH.
    DRBD Management Console.
    Online, 2008.
    Available at http://www.drbd.org/mc/management-console/.


    Footnotes

    ... blocks1
    Blocks which are target for resync are sorted in linear order. This feature allows less disk seeks and thus faster synchronization.
    ... administrators2
    DRBD MC is not in stable version yet. Current version, while I write this article, is 0.9.2.
    ...snapshots3
    See http://www.drbd.org/home/mirroring/.
    ... means4
    DRBD allows configuring split brain handler that can do anything what is scriptable.
    ... categories5
    http://www.drbd.org/home/recovery/
    ... masked6
    The service can continue to run there without needing to failover the service.
    ... others7
    As long as persistent data is on the filesystem.
    ... updates8
    http://usage.drbd.org/cgi-bin/show_usage.pl
    ... deployments9
    To be more precise, those numbers are based on data and statistics provided by DRBD nodes that have such a reporting enabled. It's obvious that real numbers should be even higher.
           

    Hodnocení: 36 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    pools avatar 22.6.2011 14:39 pools | skóre: 19 | blog: Svědek Damdogův | Opava/Praha
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    s tmavým css stylem ty obrázky nejsou čitelné díky té průhlednosti...
    Vivre libre ou mourir!
    23.6.2011 12:33 Leoš Žádník | blog: erotika
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    No to taky, ale hlavně, kterej debil tu píše anglicky? To by potom tu někdo mohl začít psát mongolsky nebo čínskou mandarínštinou...
    23.6.2011 14:27 Marek 'marx' Grác | skóre: 21 | blog: Paralelný blog | Brno / Bratislava
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Pre ľudí neschopných prečítať perex mi príde úplne zbytočné písať v akomkoľvek jazyku.
    pools avatar 23.6.2011 14:51 pools | skóre: 19 | blog: Svědek Damdogův | Opava/Praha
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Ook. Ook, ook ook ook. Ook ook ook OOK OOK! Ook.
    Vivre libre ou mourir!
    23.6.2011 18:30 abc
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Když si někdo přečte perex, to ještě neznamená, že s obsahem perexu souhlasí. Přikláním se k názoru, že autor zápisu je blbec, protože na českém webu píše cizím jazykem. Toleruji jedině slovenský jazyk, protože Slováci jsou naši bratři.
    pavlix avatar 23.6.2011 20:12 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    A já anglický jazyk, protože je to latina IT oboru.
    23.6.2011 22:12 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    To už radši anglicky než slovensky. A moji bratři teda nejsou.
    Quando omni flunkus moritati
    Nikola Ciprich avatar 23.6.2011 14:39 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Bohumín
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    no jako debil ses tu v prve rade projevil ted ty...
    Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
    pavlix avatar 23.6.2011 20:14 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Na hloupé trolly je zbytečné reagovat na jejich úrovni :) (jen osobní rada).
    23.6.2011 23:49 podlesh | skóre: 38 | Freiburg im Breisgau
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Zbytečné... ale osvěžující :-) (jen osobní rada)
    pavlix avatar 24.6.2011 00:12 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    No... možná to vážně zkusím :).
    pavlix avatar 23.6.2011 20:11 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    No to taky, ale hlavně, kterej debil tu píše anglicky?
    Mno myslím, že je rozhodně chytřejší než ten, kdo ho označuje debilem.
    22.6.2011 15:12 zxtlpn | skóre: 8 | blog: zxtlpn
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Wow, tomu říkám využití tohohle CMS (který je jinak všeobecně spíš nepřátelský). Snad jen ty zdrojové kódy by mohly využívat místního JS syntax highlightu spíš než vykreslení pomocí TeXu.
    22.6.2011 15:13 zxtlpn | skóre: 8 | blog: zxtlpn
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Vlastně na tohle tu pravidla nejsou... ale i tak by to bylo lepší vložit jako text.
    22.6.2011 17:48 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Bylo by možné obrázky vložit přímo na Abíčko příslušnou funkcí v blogu? Takhle se z původního umístění za pár měsíců či let ztratí, a článek tak přijde o dost podstatnou část své hodnoty.
    23.6.2011 18:24 abc
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Možná spíš za pár měsíců nebo let zanikne ábíčko, protože je prý ztrátové.

    Já osobně mám na webech typu imageshack fotky (cca 7000) už řadu let a jsou tam pořád všechny do jedné.
    23.6.2011 18:33 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Pokud zanikne Abíčko, zanikne i ten zápisek a ty obrázky nikde chybět nebudou. Navíc tohle odkazu na nějaký nejspíš uživatelský adresář na VŠ, který možná zanikne druhý den po promoci. A ještě do adresáře temp, tam bych fakt na trvalost nevsázel.
    22.6.2011 20:38 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device

    Článek zajímavý, trochu mě trkl odstavec, kde se najednou objevil Pacemaker, aniž by bylo vysvětleno, co to je. Text pod obrázkem webového rozhraní typograficky nezapadá do zbytku textu.

    Co by mě zajímalo a co jsem tu nenašel, je, jak je to s integrací se souborovými systémy. Správně je řečeno, že pro primary-primary konfiguraci je nutný distribuovaný souborový systém, ale nějak nechápu, jak se neclusterový souborový systém může vyrovnat s blokovým zařízením, v němž se mu pod jadernými strukturami mění data. To je těch několik jmenovaných systémů opatchovaných, nebo se blokové zařízení jeví zmražené (kam se pak odkládají aktualizace přijaté od primárního uzlu?)?

    Nikola Ciprich avatar 23.6.2011 14:51 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Bohumín
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    no pokud mate primary-primary konfiguraci, tak je nutne pouzit clusterovy fs, nebo klidne pouzit normalni fs ale musi byt zajisteno ze nikdy nebude pripojen zaroven na dvou uzlech (a pak neni moc duvod pouzivat primary-primary). pri master/slave je to samozrejme jedno...
    Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
    23.6.2011 15:43 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    To jste mi to moc neozřejmil. Mně jde o situaci, že mi stačí uzel, který bude poskytovat souborový systém jen pro čtení. Pokud má zároveň přijímat aktualizace z primary, tak i tak budu potřebova clusterový systém. Je to tak? Protože z článku jsem nabyl dojmu, že by mi na tento scénář stačil i neclusterový systém, což mi přišlo divné, a tak jsem se zeptal.
    23.6.2011 18:33 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Pokud vím (už je to nějaká doba, co jsem měl s DRBD naposledy něco do činění, to bylo ještě ve verzi 0.7 tuším), souborový systém může být připojený jedině z primary blokového zařízení. Takže DRBD není to, co chcete.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    24.6.2011 14:37 Marián André | skóre: 10 | blog: Qblog
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Myslim, ze najbezpecnejsie riesenie je v pripade primary/primary pouzit clusterovy suborovy system aj v pripade, ze "ten druhy nod" bude sluzit len na citanie.
    23.6.2011 17:53 kolemjdoucí
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    Autor blogu je zřejmě nahoře tak vymatlanej, že neumí česky. Vrať se do zvláštní školy a nauč se česky.
    23.6.2011 18:24 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: AToL: Distributed Replicated Block Device
    DRBD je pěkná věc, akorát je potřeba dávat pozor na bugy. (Třeba na ten, že za určitých okolností jedno zrcadlo s klidem hlásí nesmyslnou velikost zařízení.)
    Quando omni flunkus moritati

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.