Single Server HomeLab using TrueNAS Scale

Поделиться
HTML-код
  • Опубликовано: 2 ноя 2023
  • In this video I used TrueNAS Scale to replicated what I have done in my getting started with homelab videos. This can be used as a replacement with some downside, but also some upsides.
    TrueNas: ( www.truenas.com/download-true... )

Комментарии • 15

  • @Ddraig62SPD
    @Ddraig62SPD 4 месяца назад +1

    Worked like a charm!! Thx. The Spice display is real clunky but refreshing helps when it hangs. Glad we have RUclips subtitles as you speak so quickly ;) Great tutorial nonetheless. Much appreciated. Sub'd :)

    • @Mat-Thias
      @Mat-Thias 4 месяца назад +1

      A remote desktop client like Remmina works much better. But if you want to copy & paste, just use SSH, it makes life so much easier!

    • @perkelatorZ79
      @perkelatorZ79  3 месяца назад

      Yeah spice is a bit clunky. Remote desktop is good for some things. SSH is probably the way to go in most cases after setup as it is baked in to pretty much everything Linux/Unix.

  • @mufidskahic
    @mufidskahic 8 месяцев назад +1

    We are waiting for next week :D

    • @perkelatorZ79
      @perkelatorZ79  8 месяцев назад +1

      Next week is here: ruclips.net/video/mKfqQj9wUuE/видео.html
      Hope it is worth the wait, next week will be virtualizing TrueNAS Scale inside of Proxmox.
      Thanks for the comment!

  • @Mat-Thias
    @Mat-Thias 4 месяца назад +1

    Hi Perkelator,
    does the video "TrueNAS Scale Install And VM Setup" has any (technical) advantages compared to this one?
    My plan is using Truenas, installing a VM to run Docker (with Docker Compose or Portainer). And I want the docker instances be saved on a NFS share on Truenas, like you have described it in you video about wikijs, to gain all the benefits ZFS has to offer.
    As I understand Truenas fixed the bug with the bridged network interface: When installing a VM in Truenas, it is done automatically. (Is it, everything?)
    Do I miss anything?
    Thank you very much!
    Kind regards,
    Matthias

    • @perkelatorZ79
      @perkelatorZ79  3 месяца назад +1

      Not really, some differences yes, but no huge chances between the two maybe some small optimizations. The WikiJS video is how I am running most things I still have a system setup like this at the moment running "Prod" at my house. Yeah the bridge bug is fixed. Nothing missed that I can think of.

    • @Mat-Thias
      @Mat-Thias 3 месяца назад +1

      @@perkelatorZ79 Hi Perkelator, thank you many times for your helpful reply!
      I got stuck with playing with the server, as I have to take care of my small kids at the moment. So, your answer is very helpful and encouraging!
      All the best,
      Matthias

  • @Mikesco3
    @Mikesco3 8 месяцев назад +1

    Comment on ventoy: doing the drive in MBR allows you to boot in both older and newer PCs...
    While doing gpt will only allow uefi enabled boards and if you're eBaying older PCs I would pick what gives me the widest compatibility range...

    • @perkelatorZ79
      @perkelatorZ79  8 месяцев назад

      Yes however the opposite can be true as well. Where some UEFI systems only recognize disk in GPT. Why I said it is my preference as I have had one of these machines recently. www.ventoy.net/en/doc_mbr_vs_gpt.html
      That's is however a good point since the target of the video would be people who do not know the ins and outs of MBR and GPT. The more likely case for most people is to run across a legacy system. I'm future videos I will use MBR or explain the differences. Thanks for your feedback.

  • @shoefly757
    @shoefly757 8 месяцев назад +1

    Can you elaborate on the purpose of the LOG option when creating a pool? I just redid my system and this new update is throwing me for a loop as I am not tech savvy and not many people have set up a new pool since the update. I just want to make sure I don't need to setup log, cache, or dedup, and if I do, it is something I can set up later. Thanks!

    • @perkelatorZ79
      @perkelatorZ79  8 месяцев назад +2

      So all these options are just zfs terms and devices. There is a bit to learn about when working with zfs. I hope I can explain this well enough because it is pretty complicated.
      To understand a LOG device first you need to understand a ZIL. The ZIL or zfs intent log. Zfs does not work like a normal file system where they flush out sync writes to normal storage immediately. Where as zfs commits sync writes to a special storage area called a ZIL. The writes also stay in memory to later be flushed out with asynchronous writes as normal Transaction Groups also know as TXGs. Normally the ZIL is written to and never read from again. Once the ZIL is written to a few moments later the data is committed to main storage in normal TXGs. If zfs crashes or the OS crashes, the data written to ZIL can be read on next import (power on). So all the ZIL does is help prevent data loss in the even of a crash or power outage, in theory. There is a default ZIL on main storage.
      A LOG device in this case is what zfs calls a SLOG or a secondary log device. This is when you store your zil on a second hopefully super fast and super high endurance vdev to store the ZIL instead of on main storage vdevs. If the LOG devices has high write performance then sync writes will happen very quick. It will NOT improve asynchronous writes directly even if you force all writes to ZIL. It will only improve synchronous write latency, since it the faster device allows the sync calls to return faster. It can indirectly increase asynchronous writes in that main storage IOPS that are normally use for the ZIL will be offloaded to another device. Potentially increasing performance.
      More simple explanation is that.
      Log device stores a log of your storage changes and that log isn't lost on crash or loss of power and can be read on reboot to prevent data lose. By default you already have a log that synced writes are written to on your main storage. Setting up a log device that is super fast offloads the logs to a separate device speeding up synced writes and if the dives IOPS was very high shifting some of those read and write operations to another device potentially speeding up asynchronous writes.
      No you do not need a log device. It Is probably a waste of money in most cases. If you do want one anyway. The log device doesn't need to be big. I have seen people use Intel octane 64gb for log devices at they are fast and have high endurance.
      You do not need any of the optional devices as they are all for special use cases and normally only used in higher end storage setups where you really need the extra performance or the features they provide.
      If you would like to read a great article on zfs and the devices that goes into details I would recommend this one by Jim Salter, he is a subject matter expert when it comes to storage in general especially zfs - arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/
      Sorry for the long response, but it requires a bit of explaining. Hope this helps
      TL;DR
      You don't need any optional devices that TrueNAS offers. They all are just extra features and are only useful when you are trying min max.
      Hope this helps.

    • @shoefly757
      @shoefly757 8 месяцев назад +1

      @@perkelatorZ79 Wow! I know understand logs more than any component in my truenas! I can't explain how much I appreciate you taking the time to explain this all!

  • @shephusted2714
    @shephusted2714 8 месяцев назад +1

    do a cheap case swap and make things easier plus more drive capacity - accept no compromises - old hp gear is quite good other than the tiny cases

    • @perkelatorZ79
      @perkelatorZ79  8 месяцев назад

      Agreed I should have made that suggestion tbh as I have done that in the past with an old dell. Thanks for the feedback!