A normal report slicer can refer to only one model object at a time, so you'd need two of these on your report. And both would be called Server Name and have similar values, so this might confuse your users a little.
A compact slicer (introduced in version 11.5) may not help much in this case. It lets you combine multiple slicers into one report component, but it would still require two slicers, one for each of your Servers and Websites objects.
Global filters are being phased out with the introduction of global compact slicers, but this doesn't solve your issue either.
Unless your two model objects know about each other's Server Name value (via inference or some other mechanism), there won't be a way to condense the two report slicers or filters down to just one, even if the two backing data tables share the same column name ("Server Name").
But - ideally, none of the above would matter. If your model is set up in such a way that each website knows its specific server(s), and if this information can be retained as its cost moves to other model objects (e.g. via 1-to-1 data-based reference using Server Name within the key column), then drilling down from Servers to Websites in a report table would then only show websites associated with whichever server(s) were filtered on. Only one slicer or filter needed in this case.