@JaredBusch said in NodeBB Plugins:
Imgur (which I also noticed you stopped using
Everything that I stopped using is because they went away. Nothing was intentionally removed. At one point during an update they couldn't handle the update, I had to remove and reinstall, and the plugins were no longer available.
@JaredBusch said in NodeBB Plugins:
Sure, I have a version warning, but it is only a warning and they cause no issues.
2023-02-02T19:25:11.613Z [4567/1764] - warn: [plugins/load] The following plugins may not be compatible with your version of NodeBB. This may cause unintended behaviour or crashing. In the event of an unresponsive NodeBB caused by this plugin, run `./nodebb reset -p PLUGINNAME` to disable it. * nodebb-plugin-imgur * nodebb-plugin-imgbed * nodebb-plugin-ns-embed * nodebb-plugin-shortcuts * nodebb-plugin-dbsearch
But that plugin doesn't seem to exist.
Having the house wired up tomorrow, finally. We have two Internet providers (Claro & Teko), one on cable and one on fiber. My office is already wired to the fiber, but we are going to re-route everything so that we have both providers going everywhere. Gotta install a switch in my office and a switch in the middle of the house and put four or five access points up to get coverage.
@JaredBusch said in Local Storage vs SAN ...:
@scottalanmiller said in Local Storage vs SAN ...:
@JaredBusch said in Local Storage vs SAN ...:
@scottalanmiller said in Local Storage vs SAN ...:
It's taking a long time to upload
You know, there are no issues with plugins on my nodebb systems. You should really look closer at what your errors are.
I'm not uploading it HERE. I'm uploading it to YouTube.
I meant to click reply to your prior post, the one with the link and no video preview. But my point stands.
That's not an issue of a broken plugin. I cant find any plugin that does that. They removed the youTube plugins from the repos.
Most video game systems copied those and added headset jacks to game controllers, too, for the same reason.
@Dashrender said in What Are You Doing Right Now:
@siringo said in What Are You Doing Right Now:
@RojoLoco speakers in a couch! Not seen that before. My Mum has lights and usb chargers in hers. I thought that was top notch, but speakers go one step further.
Take it one more step - audio plug in! there are times I would love to have headset on while watching tv...
Most TV systems that I've had for the last ten years have the headphone jack either on the remote control or they have bluetooth built in for that. Can't remember a TV that I've had that didn't let me sit on the couch with remote headphones.
Roku, Fire and similar have long had jacks on the remotes. Apple and similar have long used BT.
@dafyre said in ZeroTier rules to limit freelancer access:
Again after I've connected to SERVER5 via ZT, how do you prevent me from accessing SERVER1-4 and SERVER6-15 -- or any other internal resource since the server I'm connecting to is already inside your network's main firewall?
I've never had a network where being inside the main firewall gave me access to anything. I've had customers with systems like that, but only because they chose a vendor that requires all security concepts be disabled.
By default, no business system design would be exposed through that system. Servers are not, nothing is, exposed simply by "existing on the network." Everything requires authentication and authorization, even for people on the LAN. Otherwise everyone with an Ethernet cable would have access to every file, database, backup, etc. The mayhem!
The main firewall is to make brute force and fishing attacks difficult if not impossible. That's all. Internal firewalls, application layer security and more are what control internal access.
I'm not implying that it is wrong to want to also provide security at the VPN / ZT layer. Only that it should be extra and that system to system access should never be a concern because if it is, there's a huge security hole needing to be addressed some other way.
@Pete-S said in Local Storage vs SAN ...:
DRBD, Gluster and Ceph are simply technologies used to build a vSAN.
They can be, but 99% of the time no SAN layer will be used. I've never seen Gluster or CEPH used to make a vSAN and DRBD mostly only in a lab. They are so much faster and more robust without the SAN layer that it's not popular to do that. So much of their value comes from removing the need and complexity of the networking layer since the storage itself is already replicated to each node. If you add the vSAN layer, you have to deal with a loss of redundancy (in the connection layer) and build that back in.
@Pete-S said in Local Storage vs SAN ...:
vSAN is basically local storage from several hosts networked together and replicated. It provides shared storage for the hosts. DRBD, Gluster and Ceph are simply technologies used to build a vSAN.
Technically none of those are vSAN. vSAN is a specific means of providing RLS using traditional SAN stack tech. It came about later than RLS. These three all predate vSAN concepts. Starwind does vSAN, for example.
With a vSAN approach you either have something directly on the hypervisor or more commonly a virtualized SAN appliance on a VM. This approach is only common on VMware because it is so lacking in basic features that it is necessary there, just like it is the only platform that requires hardware RAID - everyone else has software RAID built in.
The upside to vSAN is that it "looks" just like SAN in every sense and vendors trying to push you to SAN are fooled because all they see are the iSCSI or ATAoE or whatever adapters in place.
Traditional RLS like CEPH, DRBD, etc. don't have the SAN protocol layer making them simpler, faster, and more robust. There is little value in putting them in a VM so they tend to be deployed in the hypervisor directly.
Some, like Gluster, require a local driver and show up as being Gluster at the driver level. Others, like DRBD, mount as a local filesystem and are undetectable at that level of abstraction and appear as if you are using a regular local disk. Any system trying to detect local disk would believe that that is what it had.
So while the new VMware world vSAN approach has gotten a lot of attention as a way to "replace SAN" using RLS, it's mostly marketing buzz. RLS techniques are old and have been around long before virtualized SAN was imagined as having value. DRBD wasn't the first in 2007, but it was an early player in the enterprise space. But RLS goes back to the 1970s long before SAN or VMware.
Also worth noting, most SAN is actually vSAN. vSAN doesn't imply that it runs on the same box or is RLS. It's a different layer of concept.
SAN refers to block storage over a networking encapsulation protocol and has a set of protocols known as the SAN protocols that are normally used (FC, iSCSI, etc.)
vSAN is any SAN run virtualized (which is how production workloads are generally run, so lots of SAN is done this way.) Most shops building their own SANs will build vSAN without even thinking about it. It's just SAN in a VM. Being in a VM means it COULD be local, could be distant, it's not specified.
Neither SAN or vSAN implies any redundancy, only that the storage is block and over a remote networking protocol and vSAN only then implies that the workload has been virtualized making it all but a useless term (we don't call servers vServers in other contexts.)
RLS refers to the block storage being local AND replicated between nodes. Good SAN deployments have to use RLS to make themselves reliable. This is what a proper 3PAR or Clariion deployment will do - they have multiple nodes and RLS replicates so that a full node can fail. Under the hood, RLS is the only mechanism for redundancy if it truly exists.
For SAN to be truly reliable, it needs RLS. vSAN being SAN, same thing. Lots of vSAN is chosen because it is the smarter way to do SAN, but it still needs RLS to have that value. Many vSAN products include RLS setup out of the box, making people confuse the two, but the concepts are different. Lots of vSAN deployments aren't redundant and lack RLS, some aren't even local.
Starwind, as an example, offers vSAN that is non-redundant and remote (just a traditional SAN but with good technology.) And they offer vSAN that is clustered and redundant, but still remote and just a SAN cluster. Or you can move the VMs onto the hosts that they are providing storage for and make it RLS. All three are as designed.
It's complicated because vendors like VMware use concept names, like vSAN, as product names and market them as meaning something unrelated to their terms.
So all that to say vSAN is definitely an option here, if it is an RLS architected vSAN. Or another way.... vSAN is a tool, RLS is a solution. When solutioning, vSAN is one component that could be used to achieve RLS.
@Pete-S said in Local Storage vs SAN ...:
But maybe you don't need that either. Most don't.
The real question is: what are the business requirements and budget for the applications you run?
This is key.
@JaredBusch said in Local Storage vs SAN ...:
@scottalanmiller said in Local Storage vs SAN ...:
It's taking a long time to upload
You know, there are no issues with plugins on my nodebb systems. You should really look closer at what your errors are.
I'm not uploading it HERE. I'm uploading it to YouTube.
@Texkonc said in What Are You Doing Right Now:
@scottalanmiller said in What Are You Doing Right Now:
@WrCombs said in What Are You Doing Right Now:
holy busy day.
Aka "everyday"
6 back to back meetings yesterday. It sucked.
Damn. And one with me today!
@WrCombs said in What Are You Doing Right Now:
@scottalanmiller said in What Are You Doing Right Now:
@WrCombs said in What Are You Doing Right Now:
holy busy day.
Aka "everyday"
Kind of
I had to take my daughter to a Cardiologist appointment, good news and bad news there, then work has been absolutely demolished today
Eeek. That's scary!
Just recorded a forty minute video on this, lol. Uploading now.
I'm going to make a video just for this thread BUT, watch this video first while I'm making it...
@BraswellJay said in Local Storage vs SAN ...:
yet I still find myself unsure that I understand the various questions that I should be considering when making this decision.
This, too, tells you....
If you don't know, then SAN isn't viable. You'd know, you'd have no other choice.
For normal shops, only single servers make ANY sense. In super rare situations, where high availability matters AND you don't run high availability workloads (who falls into this bizarre niche???) then having HA here would always be from hyperconverged solutions, always.
MOST IMPORTANT THING>>>>>>>>>>>>>
You are asking the wrong questions. You need to start with "the goal" and ask questions that get you there.
In theory you are proposing that your goal is high availability, but other things you state prove that high availability shouldn't be on your radar. So you have a goal problem right from the start.
Because you have a goal problem, it is really easy to get tricked by the MSP scum that are trying to screw you over (they are seriously trying to screw you, I'm 100% serious when I say to walk them out the door and never speak to them again - these people hate you and your company and will hurt you just for fun.)
They are taking advantage of you. They also are not an MSP, you should not call them that as that, as well, is a sales trick to make them sound like consultants instead of sales people. They are not IT, they are sales. They don't represent your business needs, they represent the vendor. They don't propose what is good for you, they propose what makes EMC the most money. They are a VAR, they can't be in IT if they also do sales. The two by definition have to be exclusive (conflict of interest at the most core level.)
They are a VAR willing to do anything to make a quick buck.
