Startseite
Bild
Bild
  • sofort einsetzbarer und komfortabler ZFS Storage-Server für iSCSI/FC, NFS und SMB
  • Active Directory Support mit Snaps als Vorherige Version
  • mit einer komfortablen Web-GUI
  • alle Funktionen für ein fortschrittliches NAS oder SAN
  • kommerzielle Nutzung erlaubt
  • kein Speicherlimit
  • freier Download für End-User

Community add-ons wie z.B.AFP, AMP, Baikal, Proftp, Mediatomb, Owncloud, PHPVirtualbox, Pydio oder Serviio.


Bild
  • schnellere GUI durch Background Dienste
  • Support/ Updates auf neueste Versionen oder Fehlerbehebungen
  • Extensions wie komfortables ACL Management, Disk und Echtzeitmonitoring oder Remote Replikation
  • Appliance Diskmap, Security und Tuning (Pro complete)
  • Redistribution/Bundling/ Installation im Kundenauftrag optional
Fordern Sie ein Angebot an.
Details: Featuresheet.pdf

Async highspeed/ network replication (Solarish and Linux)

  • Async Replication between appliances (near realtime) with remote appliance management and monitoring
  • Based on ZFS send/ receive and snapshots
  • After an initial full transfer, only modified datablocks are transferred
  • High speed transport via (buffered on OmniOS/OI) netcat
    (unencrypted transfer, intended for secure LANs)
  • Replication is always pull data. You only need a key on the target server, not on sources


How to setup


    • You need a licence key only on a target server (you can request evaluation keys)
    • To request a license key, you need the machine-ID from menu Extensions > Get Machine ID
    • Register the machine ID key: copy/paste the whole key-line into menu extension-register, example:
      complete h:m123..4m90 - 20.06.2022::VcqmhqsmVsdcnetqsmVsTTDVsK

      Usage of a Pro license is restricted to subscription time or perpetual with an unlimited edition.

    • Group your appliances from the target system with menu extension -appliance group. Klick on ++ add to add members to the group
    • Create a replication job with menu Jobs - replicate - create replication job
    • Start the job manually or timer based
    • After the initial transfer (can last some time), all following transfers are copying only modifies blocks
    • You can setup transfers down to every minute (near realtime)

    • If one of your server is on an unsecure network like Internet: buld a secure VPN tunnel between appliances
    • If you use a firewall with deep inspection: This may block netcat, set a firewall rule to allow port 81 and replication ports


    Use ZFS replication for

    • Highspeed inhouse replication on secure networks
    • External replication over VPN links with fixed ip's and a common DNS server (or manual host entries)


    How replication works

    • Unlike other sync mechanism like rsync that compares source and target files on every run, ZFS replication generates a simple data stream that transfers a ZFS snap. On an initial send, this snap contains the whole filesystem, on next run the following incremental differential snap contains only the modified datablocks since the last run. To make this working, you always need an identical base snap from last run on both sides (the target filesystem is rolled back to this prior a send). Without this common base snap a replication cannot continue. This is a serious restriction compared to methods like rsync but unlike rsync a ZFS replication can keep two ZFS filesystem in sync even with open files and even on a Petabyte server under high load down to a minute delay..
    • On first run, replication creates a source snap jobid...nr_1 and transfers the complete dataset over a netcat highspeed connection
      When the transfer is completed successfully, a target snap jobid.._nr_1 is created.
    • The next replication run is incremental and based on this snap-pair with same number. A source snap ex jobid.._nr_2 with modified datablocks is created and transfered. When the transfer is completed successfully, a target snap jobid.._nr_2 is created.
    • And so on. Only modified datablocks are transfered to provide near realtime syncs when run every few minutes.
    • If a replication fails for whatever reason, you have a higher source than target snapnumber. This does not matter. A new source snap is recreated on next run.
    • For single filesystem replications, you can use the keep and hold job parameter to preserve target snaps.
      This will not work with recursive replications as this always replicate the same snap state and delete all others.


    In case of problems


    Basics

    • Check if basic communication/ remote control (appliance-group) via webserver on port 81 is working.
      Click on ZFS beside a hostname in menu extension - appliance group (results in a ZFS listing or an error)
      Optionally delete/ rebuild the group  from the target machine.
    • Check group members in menu Extension >> Appliance group for double entries. Especially when you rename a host it can happen that the then invalid old entry (hostname-ip) remains. You can delete this invalid group member then in submenu "delete group members".
    • Check if you have a snap-pair with same max jobid_nr_n numbers on source or target. 
(If you have deleted, you must restart with an initial replication).
    • Check if you have enough space on source and target (check also reservations and quota settings)
    • Check network settings (avoid redundant paths due two nics in same subnet) or Jumboframes/ MTU 9000.
      I have seen cases where Jumbo works with small files (build a group) but hangs with large transfers, disable Jumbo then.


    Actions

    • If the receiver and sender is starting but no data is transferred, check receive logs in menu Jobs on the target machine
      - last execution: Click on date in the line of the job (shows details of last run)
      - joblog: click on replicate in the line of the jog (shows last executions of this job)
    • Check send log on the source machine
      - see menu Jobs >> Remote log
    • If you have a former snap pair, delete the last target snap on the receiver side in case this got corrupted during last transfer. Then retry replication to check if the  replication works based on the former highest snap pair number.
    • If you need to restart a replication and if you have enough space, rename the old target filesystem (and delete it after a successful new replication). Then restart the replication with an initial run
    • Use menu jobs - replicate - monitor on both sides to monitor transfers
    • If you delete a replication job, you may need to delete remaining snaps of this job manually.
    • Try a reboot of source and target server (in case any other service is blocking a filesystem)


    Support


    If you need help, send an email to support@napp-it.org  with the following infos

    • OS release ex OmniOS 151026
    • napp-it release ex 18.03 Pro, April.02
    • napp-it Pro key


    add infos like

    • job settings (recursive and other settings)
    • last log (screenshot)
    • job log  (screenshot)
    • infos whether you have checked pool fillrate, appliance group working (checked remote ZFS list) and a reboot tried
    • other infos that can help
    napp-it 26.05.2018